Jump to content

Wikipedia:Village pump (technical)/Archive 117

From Wikipedia, the free encyclopedia

Seriously funny on the Search feature

I typed Brooks County, Texas in the search bar. There is an existing article by that name. But the one and only search result was the option "containing donnybrook" - and yes, I checked my spelling to make sure I had not caused that. I went to a different tab and again typed in Brooks County, Texas and it brought the article right up. The glitch has come and gone, but it makes me laugh. — Maile (talk) 23:25, 17 September 2013 (UTC)

Yes. I've seen that sort of thing occur, too. There must me some bug, somewhere. But it only very rarely shows up. DOwenWilliams (talk) 00:11, 18 September 2013 (UTC)
Please submit a bug to bugzilla: if there is not already one. If you can, get a screenshot or possible steps to reproduce. πr2 (tc) 00:13, 18 September 2013 (UTC)
I cannot reproduce the problem with "Brooks County" on English Wikipedia, but I guess that's the problem with intermittent bugs - they are always a bit shy. Also see How to report a bug. --AKlapper (WMF) (talk) 10:17, 18 September 2013 (UTC)
I have not been able to reproduce it either. Here and there, I've noticed odd search things like that, and I always assumed it was my input that made it happen, some slip on the keyboard. This time, it was definitely the system. Thanks for the information. Existing bug report 27411, and otherwise 155 existing bug reports that come up for "Search suggest". — Maile (talk) 11:22, 18 September 2013 (UTC)

Changing underscores (_) to hyphens/dashes (-) in URL

Resolved

- No reason to believe Google is having issues, nor any other major search engines. Just because it's not Google's ideal way, they seem to have a handle on it, and as such it's not our problem to optimize their searches if it begins to have problems. ~Charmlet -talk- 21:56, 18 September 2013 (UTC)

I know that it's the tiniest correction but it can have huge (positive) implications (although it may not be technically possible using wiki software).

Search engines, namely Google, have told many, many times that underscores are not the ideal way to indicate whitespace in a URL because if a URL is phrased .../wiki/Main_Page, "Google will only return that page if the user searches for [Main_Page]". Whereas, if the URL is phrased .../wiki/Main-Page, "that page can be returned for the searches [Main], [Page], and even "[Main Page]".

So, if it is technically feasible, I think to optimize Wikipedia's URLs, this correction should be completed. 184.146.125.96 (talk) 01:23, 18 September 2013 (UTC)

"-" are valid characters in our page titles iirc, That would break those pages titles without any real benefits. Peachey88 (T · C) 01:29, 18 September 2013 (UTC)
I just tried it. And "-" works for "Main-Page". But you're right with the "-" character in articles, it breaks the page title. Is there a feasible way to accommodate hyphens/dashes? Or, is it technically impossible? 184.146.125.96 (talk) 01:42, 18 September 2013 (UTC)
Is this really an actual problem, rathe than a hypothetical one? If one searches, for example, for United States, Google has no problem finding the Wikipedia article of that topic (it's the first search result, at least for me), even though the wikipedia URL includes United_States rather than United-States. -- John Broughton (♫♫) 03:10, 18 September 2013 (UTC)
I don't entirely follow Google's logic (what about hyphens in normal, non-programmer English? Seems a bit topsy-turvy to me), and besides which, each of our pages should restate the title a few times in the text, and be linked to from other pages using the title, so if it's not indexed properly in the URL, then that doesn't seem too much of a problem (since AFAIK, the other factors are much more impotant to page rank). — Preceding unsigned comment added by MChesterMC (talkcontribs) 10:55, 18 September 2013 (UTC)
  • Underscores are fine in URLs for search-engine match: Simply search for a quoted phrase, and notice how the matching words are highlighted in URLs with underbars ("_"), in a search-results page (see: Google site-search "main page"). I have been keenly interested in SEO for over nine years and can confirm Google has matched words in URLs with underscores for the past 9 years. As a courtesy to Google, for their company-proprietary PageRank algorithms, I will not say how high a URL match ranks, except to say it does matter. Underscores are not a problem. -Wikid77 13:23, 18 September 2013 (UTC)
  • Remarked as resolved - no reason to continue this. It's been shown, and I've tested it a bit, that Google and Bing and Yahoo! all do fine with spaces and underscores and finding the articles I search for, even with obscure and/or new ones. ~Charmlet -talk- 21:56, 18 September 2013 (UTC)

Processing time for WikiProject banner

specifically, {{WikiProject United States}}. Please can anybody assist with this and similar queries in that deletion discussion? --Redrose64 (talk) 12:41, 18 September 2013 (UTC)

I replied. Please {{ping}} me if there are further question, I am not watching that page. Matma Rex talk 13:35, 18 September 2013 (UTC)
Wikipedia:Template_limits#How_can_you_find_out.3F Werieth (talk) 15:16, 18 September 2013 (UTC)
If you follow the link I gave in the original post, you'll see that I already extracted that information. It is another user who is having difficulty interpreting it. If you can assist, please post on the original thread, not here, per WP:MULTI. --Redrose64 (talk) 15:25, 18 September 2013 (UTC)

Weird text when infobox replaced

See [1] - a vandal removed the infobox, but when it's replaced the lead starts with text about someone named Ethan. Dougweller (talk) 16:29, 18 September 2013 (UTC)

The Ethan text was a part of the (also vandalized) {{Aztecbox}}. I've reverted. Thanks for the note.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 18, 2013; 16:36 (UTC)
And thanks for fixing it. Dougweller (talk) 17:55, 18 September 2013 (UTC)
This is where 'Related changes' in the left toolbar comes in handy. --  Gadget850 talk 21:08, 18 September 2013 (UTC)

Wikipedia not remembering me and going into secure logon

For some reason, the "remember me" option isn't working. I keep randomly loading Wikipedia to find myself logged out. Sometimes it remembers me, sometimes it doesn't. And I haven't been clearing my cache or deleting cookies or anything. Ten Pound Hammer(What did I screw up now?) 03:00, 14 September 2013 (UTC)

  • Yes, as of today, I have to enter my password every time I log on. I have changed no settings; nor changed any software on my PC except for the usual automatic push-down Windows fixes. Also WP is not recalling any of the texts I have used in my edit summaries which I now have to retype from scratch each time. And I still have 'use a secure logon' turned off which we discovered was the problem creating this loss of memory last week. Hmains (talk) 03:23, 14 September 2013 (UTC)
My browser remembers edit summaries I've used before, even when I have Javascript disabled. I don't think the site itself has such a function. Many browsers have a configuration option for storing "form history". Turning it off would stop your browser from showing previous entries when filling forms (such as the edit summaries). Using private browsing mode would do the same thing. —rybec 03:38, 14 September 2013 (UTC)
This is what I was previously told for IE and it worked until today: "to auto fill edit summary: "I haven't found a way to get autocomplete in IE at https with the current setup on Wikipedia's side. If http is acceptable to you then you can disable "Always use a secure connection when logged in" at Special:Preferences, log out, close IE, start IE again and log in at http://en.wikipedia.org. PrimeHunter (talk) 16:50, 31 August 2013 (UTC)" Hmains (talk) 05:02, 14 September 2013 (UTC)
Are all the people who are having problems using IE? Have all of you disabled HTTPS? Whatamidoing (WMF) (talk) 05:44, 14 September 2013 (UTC)
I am using IE as always; my WP settings is: (not checked) Always use a secure connection when logged in. I have autocomplete (as always) turned on in IE. Hmains (talk) 06:12, 14 September 2013 (UTC)
And I also see I have been forced into the https://en.wikipedia regardless of the above noted preference setting Hmains (talk) 06:16, 14 September 2013 (UTC)
I just found that if I once force my address to be http: , then my password is remembered as well as my edit summary previously used list. I will see how long this works until something else gets screwed up. It would be nice if WP were a stable platform. Hmains (talk) 06:23, 14 September 2013 (UTC)
  • day 2: I invoke WP from my desktop shortcut. The address shows I am in HTTP:. I am not logged in so WP is not remembering me. I go to the logon panel and notice my address is now HTTPS: . I do not enter any information on the logon screen; I simply back out of it to the WP main page. It now shows I am in HTTP: and I am logged in with my suddenly remembered user id and password. No wonder people have a hard time when experiencing/describing this behavior (see above). Hmains (talk) 15:32, 14 September 2013 (UTC)
Something very similar happens in Firefox 23.0.1 - until recently, WP:SUL worked fine, and I could switch sites and edit immediately. But now, if I am logged in on English Wikipedia, and then go somewhere else (like commons:, meta: or fr:) it often appears that I am not logged in (links upper right are Create account/Log in, not the normal 6+). Clicking "Log in" allows me to log in; but I have found that logging in is not actually necessary: waiting about five seconds and then going for Ctrl+F5 convinces the site that I am, in fact, logged in. --Redrose64 (talk) 15:40, 14 September 2013 (UTC)
Note that the "am I centrally logged in?" check isn't run for every page view to prevent overloading the servers. It is run once every 24 hours and every time you visit Special:UserLogin; the 24-hour flag should also be being reset on a successful login (note to self: T56147). Normally the JavaScript involved should be reflecting the successful "am I centrally logged in?" check by replacing the #p-personal bar or by changing the page location, but if you have JS disabled in your browser then the auto-login is by necessity silent. If you do have JS enabled and are still seeing no notice of the login, please do check for and report any JS errors. BJorsch (WMF) (talk) 12:25, 15 September 2013 (UTC)
As for being logged in here on enwiki and then going to frwiki and being not logged in, that in particular shouldn't be happening with SUL. My first suspicion is that you somehow have a bogus cookie that is hiding one of CentralAuth's cookies; can you reproduce it if you clear all cookies and then close and reopen the browser? BJorsch (WMF) (talk) 12:25, 15 September 2013 (UTC)
This is almost exactly what I described here more than a week ago, and I am continuing to experience the very same, weirdly random problem. It does remember that I'm logged in - but some pages display as though I'm not. As you say, no need to actually "log in" again, I just go to that page and then straight back to whatever article I was looking at. Most of the time that seems to "work", but not always. And yes, I am using IE. Cgingold (talk) 22:43, 14 September 2013 (UTC)
FWIW, this sounds like a caching bug of some sort (which could be in your browser, in WMF's caches, or in some cache in between you and WMF's servers) rather than an issue with SUL. BJorsch (WMF) (talk) 12:25, 15 September 2013 (UTC)
  • Whatever it is, this problem has not been fixed and there seems to be no activity by the people responsible for this mess to fix it. Hmains (talk) 02:13, 19 September 2013 (UTC)
    • Hmains, I'm sorry that you're still having this frustrating problem. BJorsch named above the three different places where this problem may be caused:
      1. your own computer,
      2. the WMF's servers, or
      3. a server in between you and the WMF's servers.
    • Each user is necessarily responsible for cacheing problems that appear in his own browser. Please follow all the steps at WP:BYPASS and let us know if that (hopefully!) solves the problem for you. If the problem is the WMF's caches, then it will likely be fixed relatively soon. If the problem is at a third-party server in between you and the WMF (e.g., on your corporate or university network or your local ISP), then I'm afraid that there is often nothing that either you or we are able to do about it except wait for the third-party server to update its cache. Whatamidoing (WMF) (talk) 18:53, 19 September 2013 (UTC)

Import URL from Wikidata

The {{URL}} template doesn't clean up the syntax when importing the URL from Wikidata. See the infobox of Paniqui, Tarlac, for example. The URL should read www.paniqui.gov.ph when using this template, but instead it shows the entire string (http://www.paniqui.gov.ph/). Can this be corrected? BTW, I haven't seen any bots adding links to Wikidata. Is it too premature to import Wikidata? -- P 1 9 9   13:19, 16 September 2013 (UTC)

{{#property:P856}} used on Paniqui, Tarlac returns http://www.paniqui.gov.ph/ with an encoded colon, while wikidata:Q56457 says http://www.paniqui.gov.ph/ with a normal colon. {{URL}} uses Module:URL which does not have code to handle an encoded colon. I don't know what causes the colon to be encoded. PrimeHunter (talk) 15:14, 16 September 2013 (UTC)
Thanks for the report. We're looking into it. Needs to be fixed. --Lydia Pintscher (WMDE) (talk) 10:06, 19 September 2013 (UTC)

Find template with parameter

Hello. 1) Is there a way to find which articles have the parametrer {{flagicon|Cyprus}}? 2) If yes, is there a way to find which articles of a specific category have the parametrer {{flagicon|Cyprus}}? Thx. Xaris333 (talk) 19:41, 18 September 2013 (UTC)

What is your goal? Werieth (talk) 19:43, 18 September 2013 (UTC)
  • Use WhatLinksHere of the {Country_data_Cyprus}: The related data-size template is typically a good indicator about using "Cyprus" so just see:
That should be close to what is needed. -Wikid77 (talk) 22:10, 18 September 2013 (UTC)

Thx. But is not what i want. I want a way to find the articles that had a specific parameter of a template. Xaris333 (talk) 15:02, 19 September 2013 (UTC)

What are you trying to do? If you explain your goal we can find a solution for you. Werieth (talk) 15:04, 19 September 2013 (UTC)

Bug in selective undelete of a deleted page

Copied from my user talk page

Continuation

This is bug 43911. Graham87 08:17, 19 September 2013 (UTC)

Redirect status following a pagemove

When moving a page, there is an option to specify whether one wishes to leave a redirect. If one checks the appropriate box, a redirect will be created from the old title to the new title; if one unchecks the box, the creation of a redirect will be suppressed.

However, regardless of which option an editor chooses, the Move succeeded screen always notes at the bottom that a redirect was created. The function of creating or suppressing a redirect works just as it should, but the same message is always displayed. How could this be fixed? Thank you, -- Black Falcon (talk) 05:42, 19 September 2013 (UTC)

It's presumably a MediaWiki page. Copy/paste the text into the search bar and tell the system to search only for MediaWiki pages. You may be able to find it that way, or if there's a link in the message, use WhatLinksHere for the target and restrict the results to MediaWiki pages. Presumably you're an admin, since only admins get the "suppress creation of a redirect" option; if that's so, you'd be able to edit the message yourself. Nyttend (talk) 06:33, 19 September 2013 (UTC)
Oops, I'm sorry; I'm sleepy, so I had my eyes closed while typing this. Nyttend (talk) 06:34, 19 September 2013 (UTC)
I've fixed it for you. That's an impressive touch-typing ability you have, by the way. :) — Mr. Stradivarius ♪ talk ♪ 09:01, 19 September 2013 (UTC)
Thanks, Mr. Stradivarius! It was 1:34 AM, and I didn't feel awake enough to retype it. For some years, I've had a good deal of work doing transcriptions, so I've learned to be able to type while looking at something else or at nothing in particular. However, you'll note that I can easily hit the caps lock while thinking that I've hit the shift! Nyttend (talk) 18:08, 19 September 2013 (UTC)
This is bug 45348. Graham87 08:07, 19 September 2013 (UTC)
Thank you. -- Black Falcon (talk) 03:46, 20 September 2013 (UTC)

August page views just got deleted for all of WP

Resolved

At http://stats.grok.se/ all of August pageview statistics have been deleted. They were there yesterday. At Wikipedia:Help_desk#August_page_views_just_got_deleted_for_all_of_WP, I sought answers and remain unsatisfied.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:54, 19 September 2013 (UTC)

You may have to contact User:Henrik - that's the link in the FAQ section. It's not an official Wikipedia site, so I don't think anyone else here can do anything about it. There is a big blank, though. Peridon (talk) 17:12, 19 September 2013 (UTC)
The info might be at http://dumps.wikimedia.org/other/pagecounts-raw/2013/2013-08/ - but don't ask me how to get at it. It seems to be the source for the grok data. Peridon (talk) 17:17, 19 September 2013 (UTC)
He is inactive and the data that the site uses is from WM isn't it?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 17:18, 19 September 2013 (UTC)
Not been seen since June. And Misza of the bots I, II, and III which is not running, is also missing since May - perhaps there's a conspiracy to kidnap key people. I should be safe, anyway... That dumps link is WM, but what you do with it is beyond me. Peridon (talk) 17:23, 19 September 2013 (UTC)
(edit conflict)Yes, hence Peridon linking you to the data dumps. Henrik's site hosts a copy of the data rather than anything else - so this doesn't have implications for the actual existence of the information, just how easy it is to get it. If you're interested in obtaining something you can grab it from the link above. Ironholds (talk) 17:25, 19 September 2013 (UTC)
Can an active user create a new (and updated) tool that accesses the data that exists. This tool needs improvments anyways.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) —Preceding undated comment added 17:44, 19 September 2013 (UTC)
Undoubtedly someone can, but whether they will or not is a different question... Henrik does take fairly long breaks, so he will most likely be back. When, that's another question. Peridon (talk) 17:55, 19 September 2013 (UTC)
Statistics such as http://stats.grok.se/en/201308/The%20Sound%20of%20Music%20by%20Pizzicato%20Five can be found, was there something else? Peter James (talk) 18:50, 19 September 2013 (UTC)

Strange issues with image files

Hello, there, I'm having problems with adding image files onto pages. Normally it works just fine, but sometimes, both a while ago and recently, something goes wrong. This happened to me once before, when I was editing the page "Baragon", and it happened to me just now while editing the page "Hoverboard". The image comes in fine, but to the top left corner of the picture, text that reads: "Image:" can be seen. And directly below the image, there is text reading "|250x450px|alt=". I've tried different combinations of spacing in the infobox, I've changed the format from thumbnail to framed to frameless, I've both added and removed the text reading, "File:" from "File:Hoverboard.jpg", but nothing works. Someone has since cleaned up he issue on the Baragon page, but I don't know what I'm supposed to do. --Matthew (talk) 21:10, 19 September 2013 (UTC)

This edit has fixed Hoverboard. I couldn't see a recent problem in the history of Baragon. The problem is that although some infoboxes expect the full image syntax in the |image= parameter, others expect the filename alone - they fill in the rest themselves. --Redrose64 (talk) 21:31, 19 September 2013 (UTC)

Misplaced tabs when zoomed in

Dear editors: Because of poor eyesight I often view web page text a little larger than usual by using the "Control +" feature in Firefox. I've been doing this successfully with Wikipedia for months. In the last couple of days, though, when I use this key combination the tabs at the top of each article or talk page display correctly for a moment, and then everything after the "Talk" tab shifts down and completely obscures the title of the article, while the first two tabs remain in the correct locations. I think what previously happened instead was that the search box would be shortened or some of the options would appear as dropdowns, but I can't remember exactly. This seems like a bug. —Anne Delong (talk) 12:55, 12 September 2013 (UTC)

I have Firefox 23.0.1 and use the View/Zoom In option from the menu bar. What I see on the menu selection is that the Zoom In is the equalivant to "Control ++", and I assume that's what you are referring to. I haven't noticed anything new or different. Generally speaking, the page zoom remains permanent from login to login at all Wikipedia articles unless I decide to change it. — Maile (talk) 13:03, 12 September 2013 (UTC)
I just tried this out, and it does seem that when the right and left tabs meet due to a high zoom level, the right Vector tabs move under the left tabs. I don't have any way of knowing if this was always the case or what may have occurred in the past, though, and I'm not sure how it could be corrected if unintended. equazcion (talk) 13:06, 12 Sep 2013 (UTC)
I don't get this in either Vector or Modern skin, so maybe there is another contributing factor that makes it happen for you and Anne Delong. It seems to me that a year or so ago, I was getting a phenomenon with article title coordinates dropping down into the text, and somebody fixed that. — Maile (talk) 13:16, 12 September 2013 (UTC)
It has always been this way, ever since Vector was introduced. I'm positive there is a bug ticket for this, but i can't find it right now. —TheDJ (talkcontribs) 13:43, 12 September 2013 (UTC)
Well, since it seems that it doesn't happen consistently, perhaps I've been doing something differently. I notice that when I rotate my laptop/tablet to portrait mode, I actually have to zoom out substantially before the page tabs look normal. In any case, it's not a problem for me; if I want to see the article title I can always zoom out temporarily; the title text is certainly large enough even when other text is small. I just thought if it was new it should be reported. —Anne Delong (talk) 15:14, 12 September 2013 (UTC)
It depends a lot on the available space. So if the tabs or something grew by just 1 pixel, that might perhaps be enough to put it over the edge at your preferred zoom level in combination with your specific screen width. —TheDJ (talkcontribs) 17:15, 12 September 2013 (UTC)
Actually, no it hasn't always been this way. The right-hand tabs used to slide behind the left-hand tabs. They now shift below the other tabs. This changed when Vector was overhauled to use H3 headers instead of H5 for the portlets, which changed a lot of the metrics of the tabs. Edokter (talk) — 10:49, 15 September 2013 (UTC)
Yes,I understand about screen real estate; I have written software myself. However, in the past when there wasn't enough space, more sensible things happened, such as moving some items to a pop-down list, making the search box narrower, etc., rather than covering up the title of the article. Anyway, I was not complaining, just pointing out a possible bug. —Anne Delong (talk) 21:38, 12 September 2013 (UTC)
  • There's a rather elegant feature in Gadgets which shifts a lot of the tabs and sidebar links to a drop-down; it's under Preferences > Gadgets > section Appearance > "Add page and user options to drop-down menus on the toolbar...". It has the unusual quirk of sometimes adding a blank tab, but otherwise is very useful for condensing these and avoiding the two-line header problem. Andrew Gray (talk) 22:09, 13 September 2013 (UTC)

@anyone, Anne Delong, and Maile66: I'm trying to learn exactly how editors use the Wikimedia sites, with accessibility tools like screen magnifiers, and zoom settings. If you could reply to the short list of questions at Wikipedia talk:WikiProject Accessibility#Visual impairment - what settings, software, or other tools are used to compensate, that would be immensely appreciated. Also, if you know of anyone else who might have useful input, please help me get the word out? Much thanks. –Quiddity (talk) 19:24, 20 September 2013 (UTC)

Forcing Convert into huge Lua modules

This is a major announcement about rewriting Template:Convert.

There is an impending upgrade, expected in October 2013, to switch Template:Convert, from the current collection of small, efficient subtemplates, to use gigantic Lua Module:Convert (tested) and others of several thousand lines each. This will be a drastic new architecture, leaving the dynamic small subtemplates where updates had affected only the related pages, into an old-style software mega-system ("one size fits all") where one Lua change requires reformatting all {convert} articles (nearly 560,000 pages). Consequently, all related Lua modules (Module:Convert/data) will be full-protected, and no new old measurement units can be added, or altered, except by admins, and will require reformatting all pages in Wikipedia which use {convert}. Meanwhile, the old {convert} will be usable for emergency fixes or incompatible parameters, as Template:Convert/old, to allow custom format changes, or instant new units (such as "cuerda" or "US teaspoon") without triggering the 3-day(?) reformatting of all 560,000 pages which use Lua {convert}. During the transition period to Lua, to determine long-term feasibilty, it will be possible to streamline old {convert} into a smaller set of dynamic templates, where perhaps 40 subtemplates would provide all basic conversions for some other-language wikipedias which cover U.S. topics or Imperial units with metres/feet, km/miles, kg/pounds, or ml/pints in cultural descriptions, while most scientific articles would need only give metric units in other languages. If the continual, year-long(?) reformatting of articles, which is triggered by updates to Lua Module:Convert, becomes a performance bottleneck, then a return to the streamlined Template:Convert might be the result, or else split Module:Convert into redundant sub-modules to reformat only fractions of the 560,000 pages whenever the Lua {convert} is updated. We have confirmed, via wp:CS1 Lua cite Module:Citation/CS1, how changing the one module will, absolutely, trigger the cumbersome reformatting of 2.1 million Wikipedia pages for days, every time, for even a tiny change. These problems, of Lua-triggered year-long reformatting of pages, are a new challenge because the prior mega-templates were "too slow" to alter very much, and remained unchanged for months, to not trigger reformatting millions of pages each week. Anyway, we have needed a chance to streamline and reduce Convert's 2,800 subtemplates, and this transition to Lua {convert} can provide a time period for that improvement. -Wikid77 (talk) 23:10, 17 September, 00:29, 20 September 2013 (UTC)

Maybe this is a dumb question, but why not just merge the second parameter into the module name? convert|123|lb|kg --> convert-lb|123|kg Wnt (talk) 06:56, 18 September 2013 (UTC)
Yes, separate templates for major units is an excellent way to avoid reformatting all pages, such as a cvt-m (used 45%) or cvt-ft (used 40%) or cvt-km used in 32% of pages, and then all other conversions would then affect less than half of all pages. -Wikid77 21:50, 18 September 2013 (UTC)
Conversion is tricky! Including aliases, there are over 1000 units (see this master list), and over 4000 templates (see this old list created by Osiris). In principle, there could be a different template and a different module for each of the 42 unit types, but then instead of "convert", the wikitext would have to say "convert-length", so it would be better to see if the servers can cope with a single template and main module.
To handle the addition of new units (such as the "cuerda" and "US teaspoon" templates which Wikid77 recently created), the module provides Module:Convert/extra which is an almost empty list that is checked when the main convert module encounters a unit it does not recognize. I don't see a reason that the extra module should be protected, so anyone could add a new unit there, and the new unit would be instantly available with very little overhead to the servers.
It is highly likely that the convert module will need tweaking, and that will invalidate the cache for many pages, as described above. However, the devs told us to replace templates that do a lot of work, and the module should stabilize after a month or two. We'll have to see how much trouble mega-modules cause. Johnuniq (talk) 10:46, 18 September 2013 (UTC)
Actually I was proposing to add a unit (it could be either the source or the destination unit, doesn't really matter, whatever people decide they prefer) to the name of the template for each case: convert-lb rather than convert-weight. The idea would be that convert|A|B|C -> convert-B|A|C could be done by bot without any thought involved. That involves a much larger number of templates, some of which could indeed call common modules like a convert-length module, but each overall kind of quantity can have code without dependencies on each of the others, and even within a conversion type the templates would only all be reprocessed if a common module like convert-length itself were changed, rather than when anything affecting convert is changed. Wnt (talk) 14:53, 18 September 2013 (UTC)
Also, I'm a bit confused by your proposal for Module:Convert/extra. Is there a way to call that without using Module:Convert? Because as I understand it, Lua modules are run when the page is parsed, so a change in Module:Convert/extra should either not affect how convert works at all, or else should trigger it to be rerun wherever it appears. There's no way to build just part of a module/template on Wikipedia without redoing the whole thing, is there? Wnt (talk) 15:00, 18 September 2013 (UTC)
  • Templates and modules allow dynamic linking only if used: Yes, only a portion of the total 560,000 pages would be affected by using Module:Convert/extra for new units, and only those pages would need to be reformatted when adding yet another new unit. The current markup-based template {convert} works similarly to handle each specific conversion with only a few subtemplates (among 2,800 combinations of options). However, having separate, dedicated templates for cvt-km and cvt-m and cvt-ft (for feet) would almost always limit most feature upgrades to affect only half of total conversions, for years to come (even when WP has 10 million articles), which is how the current Template:Convert/km and Template:Convert/m limit the reformatting to only 45% and 32% of total pages with conversions. Meanwhile, we need to improve the Lua conversions to adjust fraction precisions, such as which has the same precision as 3-decimal 7.004. So, in October, there would be fewer changes needed in the Lua version, as being closer to the current precisions of markup-based Convert. -Wikid77 (talk) 21:50, 18 September 2013 (UTC)

Could I quickly ask what the best options for Simple English Wikipedia would be? Wikid77, you will probably remember that we imported the entire set of subtemplates last year sometime. Should simplewiki continue using those or switch to modules? There are less than 7,000 pages using {convert} anyway -- in case you wanted to do a trial run on a smaller project before implementing it here? Osiris (talk) 02:36, 19 September 2013 (UTC)

  • Convert works on simplewiki, so if it ain't broke...: There is almost no advantage to switching to a highly complex Lua version of Convert, if following the "80/20 Rule" of fixing problems which hinder 80% of quality. Convert is basically: a ~0% quality problem (never 80%), because any bugs can be fixed within hours/days not months. As noted above, an alternate improvement (long-term) would be dedicated templates for only metres/feet, km/miles, kg/pounds, or ml/pints, and thereby any new features updated in {convert} would affect perhaps reformatting only 25% of all conversion articles. The switch to Lua convert might be a "less-optimal" solution, which incurs numerous complexities for checking precision and derailing the current system of several people who know how to fix many quirks of markup-based Convert. A sideshow arena has been the slow reduction of Convert subtemplates (as a type of "sub-optimization") to remove a mere thousand Convert subtemplates when Wikipedia is drowning in a "zillion" (millions) of trivial templates which could be removed instead. There are over 104,000 types of infobox templates, at that level of detail, and keen reductions among those would simplify more pages than combining rarely-used Convert subtemplates which affect a 2-number phrase. To make major tangible progress instead: analyze quality problems in numerous articles, then count which few quality aspects (if improved) would tend to improve "80%" of article text, for relatively low effort expended. For example, a real improvement for WP would be to create a "list-formatting Bot" which would transform hacked markup lists which contain over-bolding and "<br/>" lines by Bot-editing those lists into typical indented-bullet lists; then run that Bot on thousands of articles where a real benefit could be achieved by rapid wiki-formatting of text. Another major improvement would be a de-redlink Bot which removes "40 redlinks" from all those overlinked pages of garage bands and their 7 non-notable albums or 33 related musicians who never got articles. Focus on major quality problems: over-bolded lists, massive redlinks, or bare-URL cites, and improve the tools which help users to quick-fix those major issues. Rewriting Convert in Lua is just a distraction, of relatively little improvement, in comparison to mass copy-editing of text. -Wikid77 (talk) 04:41, 19 September 2013 (UTC)

@Wnt: To answer your question at 15:00 above, the plan is a user would always use a template (currently {{convert/sandboxlua}}) to do a convert, and that template always invokes Module:Convert, which in turn always requires two other modules (one for conversion data, and one for text that would be translated for use on another wiki). The main module has logic which says "if the unit I'm looking up is not found, require the extra module and use it to lookup the unit". The result is that the page using a convert template would depend on the extra module if and only if the unit being converted is not in the main data module. Johnuniq (talk) 09:40, 19 September 2013 (UTC)

If you can actually do this - have a Lua run for a specific page keep track that a module in it was not required, and not rerun based on changes in it - then you should be able to have the main convert template only require the sub-modules it actually uses for any specific unit conversion. Changing the conversion of gallons to ounces shouldn't affect meters to feet, if they are split up properly -- indeed, I'm thinking almost any widely used module should have a way of requiring only the parts it depended on for a particular run. But what I don't understand is --- where is this information kept? It's not in the output of the #invoke, it's not in the module source code - is there some set of wiki global variables that stores the inverse of "what links here" for each page? Wnt (talk) 19:18, 19 September 2013 (UTC)
The information is stored in the same tables used for "what links here", in this case the templatelinks table that tracks template transclusions. The table is indexed such that it can be used in both directions. This is updated each time you save a page to indicate which templates and modules were used to render it. (The entries for any given page are also updated by job queue tasks when one of the page's transcluded templates or modules is edited.) – PartTimeGnome (talk | contribs) 22:39, 19 September 2013 (UTC)
A year ago, I was toying with the idea of having separate tables for each type of unit—data for units like meters and feet would be in a "length" table, while grams and pounds would be in a "mass" table. At the back of my mind, I am keeping open the possibility of going back to that idea, but I think that extra complexity would need to be justified by trial-and-error where we find that the enormous single table is unsatisfactory in practice. Johnuniq (talk) 01:58, 20 September 2013 (UTC)
@Johnuniq: I've looked over your table at User:Johnuniq/Conversion data -> Module:Convert/data. It would indeed be hard to pre-sort an unknown unit according to what kind it is, and of course any table meant to sort out what kind it is in advance would need to be updated quite a bit and affect every usage... however, you should be able to break this down pretty easily by simple alphabetical order. If your script were adjusted to produce several Module:convert/data/x tables according to the alphabetical range of the first letter of the unit, the main Module:convert could require that section specifically. As a result you could update units with far less burden on the server.
It would also be nice to see the logic in Module:convert be more modular where there might be changes, but maybe unit type isn't the right thing there either. There are just a few features like "Mach" conversions which seem to take up a lot of code there, and which might be prone to further tinkering, say, when somebody starts riddling out what the increase in carbon dioxide levels does to the scheme. Maybe a few things like that can be delegated out to a special set of logic functions required only when needed? Wnt (talk) 18:40, 20 September 2013 (UTC)
Yes, alphabetical sorting would have an advantage, but I don't see why units would need much updating after a month or two. The reason the current templates are continually updated is that people keep finding an option that generally works, but which has not been implemented for a particular unit. The actual unit data almost never changes because Jimp went to a lot of trouble to make the data correct (and I have copied almost all of it). New units can be added to the extra table, and put in the main table once a month, or whenever. One issue regarding alpha order is that I will be maintaining data tables on other wikis—for example, see bn:Module:Convert/data (with sample converts here). Arranging units "by type" means only one table would be needed for a particular convert, although an additional table would be needed to determine which table to use.
When I was still concerned about performance (before it became apparent that speed is not a problem, see my sandbox), I did an ugly hack suggested on wikitech-l, and it turns out that storing a table of data in a single string and doing a binary search on that mega-string is faster than indexing a table (see test2 with background here). However, it is now clear that dirty tricks are not needed. Johnuniq (talk) 23:53, 20 September 2013 (UTC)

@Osiris: The convert module is in use at the Bengali Wikipedia—some results can be seen here. It's exactly the same as the module proposed for use here, except that the Bengali editors have provided translations for unit names and related text that they use. Johnuniq (talk) 09:40, 19 September 2013 (UTC)

  • This angle: are there any functional improvements (known, thinkable or should-be made possible) that were postponed because of markup-code complexity? If so, Lua could allow them. I am not talking adding new units. -DePiep (talk) 09:52, 19 September 2013 (UTC)
There were many requested features for rounding the 1st amount, rounding output to near=5, 25 or 50, and inserting custom text between numbers, but Template:Convert/f was written to allow them. Many of those features are also in the Lua Convert module.
  • So even a tiny changes causes all 560.000 pages to be refreshed. Exactly who declared that a performance issue/problem? Has mw or so requested this rethinking? And we could consider to use an module edit regime that parks minor edits to be introduced once in every x months (or when a bug appears). -DePiep (talk) 10:05, 19 September 2013 (UTC)
With new units placed in small Module:Convert/extra, then only a small number of pages would reformat to show the new unit in related pages, as compared to waiting for all 560,000 pages to reformat to display the new unit among them.
  • If having 500,000 pages in the job queue worries people, then I might not have made many favours with this edit yesterday. (Pages added to the job queue: 7.8 million.) To a certain extent, having lots of pages in the job queue is inevitable after the switch to Lua: modules that have only just been written are likely to need more tweaking and updating than templates that have been around for years. A lot of this problem should disappear after the really high-use modules stabilise and the focus switches to converting lesser-used templates. Also, it may be a mistake to focus purely on the number of pages that need updating - pages transcluding templates that have been converted to Lua will be processed a lot faster than pages with the old wikicode templates. Although, of course, it is always good to code templates so that they don't use too many resources. Module:Convert/extra seems like a good way to accomplish this to me. After Module:Convert stabilises, the main module will hardly be edited at all, and new updates can be added to Module:Convert/extra with hardly a dent to the job queue. This seems worth it to simplify the current Template:Convert family, which is very hard to comprehend due to the large number of subtemplates and the complex interactions between them. — Mr. Stradivarius ♪ talk ♪ 10:57, 19 September 2013 (UTC)
If you think the one-line Template:Convert/LoffAoffDbSoff is hard to comprehend for showing number, unit name, and result in "(__)", then imagine a user reading Module:Convert with 3,000 lines of Lua script, and ask them where the "(__)" are displayed by Lua. We know we are creating Lua modules which "no one" else can understand, but perhaps we could write a programmer's guide to Module:Convert, to explain the complexity. Meanwhile Template:Convert/old allows updates to the well-known features. -Wikid77 00:29, 20 September 2013 (UTC)
Well, Wikid77, we are not forced to do so -- or to do whatever. As you know. Then, about these 560.000 (half a million) pages that are to be changed. Earlier, {{cite book}} was about that same number. It was controlled. -DePiep (talk) 22:24, 19 September 2013 (UTC)
When I wrote the Lua script for {cite_book}, I tested many parameters and knew the order of the 50 major parameters, plus others reviewed the results long before {cite_book} was transitioned to Lua. There were various discussions to add several more minor parameters, but I noted the impact of updates to continually reformat 1.9 million pages (now 2.1M), and updates were delayed for months. A major problem with mass reformatting (other than WP grinding for days) is how Special:WhatLinksHere is not fully updated for at least 4 days, as oppposed to minimal reformats which can update the backlinks within one hour. -Wikid77 00:29, 20 September 2013 (UTC)

Loss of session data

I was not signed out and didn't have to sign in again, and yet one of my edits gave me "Sorry! We could not process your edit due to loss of session data". I had to do this edit over.— Vchimpanzee · talk · contributions · 21:18, 19 September 2013 (UTC)

This happens when you leave the editor open too long, and I suspect when things happen on the server side too. Graeme Bartlett (talk) 21:29, 19 September 2013 (UTC)
The first problem wasn't likely to have been a factor. My previous edit was five minutes earlier. If it was just me, maybe there's not a serious problem.— Vchimpanzee · talk · contributions · 21:35, 19 September 2013 (UTC)
Essentially, what happens is that when you click "edit", you're sent a timestamped token and the server keeps a copy. When you click "Save page", you send that token back, and the server compares it against the copy. If they match, the save is processed; but if there is a mismatch (possibly: your browser fails to send the token back; it's been corrupted in some way; or the copy token no longer exists on the server - most probably because it's expired), the save request is refused with the error message that you described. Please note that it has nothing to do with whether you are logged in or not - anonymous editors can experience the same problem. --Redrose64 (talk) 21:42, 19 September 2013 (UTC)
If you're wondering why these tokens are used, they protect against cross-site request forgery. Without them, some other website could have a button that causes a user to inadvertently submit an edit to Wikipedia just by clicking it. With edit tokens, Wikipedia will reject such an edit as it lacks one. I.e. the edit token ensures someone really visited the edit page before allowing an edit to be saved.
BTW, you don't need to do the edit over from scratch. You are sent a new edit token along with that error message. Just click "Save page" again and your edit should save. – PartTimeGnome (talk | contribs) 22:51, 19 September 2013 (UTC)
It's not just you, but it's not a substantial problem. I occasionally get this even when making a small change that took just fifteen seconds. I've always assumed that new tokens become effective at stated intervals; the longer your window is open, the more it is that a change will have happened, but it's still possible that you opened the window five seconds before the new token became effective. Just click the "save" button again and repeat several times if necessary; it should always go through eventually. If somehow you try over and over and over again, you still should be able to save the contents in a sandbox. Nyttend (talk) 23:46, 19 September 2013 (UTC)
It's just done it on me at Wikipedia:Articles for deletion/Grand Duchy of Flandrensis (Grand Duchy of Flandrensis (Second time) nomination). I opened the edit window, typed two sentences and saved. No time gap. It session dataed me three or fory times, so I copied my edit, closed and reopened and pasted. This time, it saved. I can't remember what the session data message I've seen previously looked like, but this little red message doesn't look familiar to me. Peridon (talk) 19:20, 20 September 2013 (UTC)

green notices

(I don't know if this is best here or at Proposals, so pardon me if it is in the wrong forum.) I really like the idea of green squares to indicate unviewed changes (on my Watchlist page); how-ever, at least on my screen I can hardly see the difference between green and gray-green. I have to look very closely adn even then am not sure which color a square has (depending on the squares above and below it). Is there some way to make the difference easier to see? In addition to color, how about a change in the symbol? Kdammers (talk) 00:54, 20 September 2013 (UTC)

Wikipedia:Customizing watchlists has a few things you can do. equazcion (talk) 00:58, 20 Sep 2013 (UTC)
You can change the icon for updated entries in you watchlist by adding the following code to your common.css:
/* green bullets for updated entries in watchlist, history and recent/related changes */
li.mw-changeslist-line-watched,
li.mw-history-line-updated {
    list-style-image: url(//upload.wikimedia.org/wikipedia/commons/c/cd/ChangedBulletVector2.png);
}
Note that you have to specify a direct URL to the image, not a Wikilink! In this case, File:ChangedBulletVector2.png was used which yields "". You'll find a list of other matching bullets for vector and monobook skins on the file's description page, but you can also use other images as long as they have the correct dimensions. --Patrick87 (talk) 13:34, 20 September 2013 (UTC)
@Kdammers: you mention squares, so you're probably using Monobook, not Vector. You should make a change like this to Special:MyPage/monobook.css (not common.css, because it's not the same for all skins). There is related material at Wikipedia:Village pump (technical)/Archive 113#Green bullets in watchlists (also Wikipedia:Village pump (technical)/Archive 112#Green highlighting of changes since last visit doesn't work anymore but that's not so helpful). --Redrose64 (talk) 16:05, 20 September 2013 (UTC)

visible

Is this edit of mine showing? To me the edit does not appear on the actual page. Pass a Method talk 04:38, 20 September 2013 (UTC)

Seems to be showing for me. I just purged the page anyway though, check again. equazcion (talk) 04:47, 20 Sep 2013 (UTC)
My comments are not showing on this page either. I was only able to reply/view by going to "difference between revisions" in page history. I think i might have a virus or something. Pass a Method talk 06:01, 20 September 2013 (UTC)
Oh, its showing now!!. It appears on and off. Pass a Method talk 06:03, 20 September 2013 (UTC)
  • On rare occasions the old page redisplays after edit: So, please do not panick, and you did the right thing by checking View History to confirm your edit was saved. Whenever the old revision is redisplayed, after an update, then wait 20 seconds and click the browser refresh button, and usually the new revision of the page will appear. The problem is so common I have seen it every few months for years. Perhaps some other users can explain why the re-display of old revisions occurs, and if there are plans to fix it. It might be related to the "need read-lock" problem which allows 2 editors to update the same old revision, and the 2nd editor overwrites the changes of the 1st editor, during the same minute. -Wikid77 (talk) 14:33, 20 September 2013 (UTC)

Top 5,000 templates

No hurry on this, but I want to see a list of top 5,000, beyond the typical list of the top 3,000 most-used templates in:

When fixing that list (to correct typo names "Template:Dw" and "Template:Twin_Falls,_Idaho"), which had been redlinked 1-4 months, I noticed how there had been a redlink template sitting outside the list, at rank 3,001, just out of view to be seen for correction, before re-ranked as 2,998. With a larger list of 5,000, then more redlink typo-templates could be fixed before they become listed in the report of the top 3,000. No hurry, just a way to reduce future problems. -Wikid77 10:40, 20 September 2013 (UTC)

I have no opinion on whether this should be done, but your reason for doing it isn't terribly convincing. You'd just have the same problem with rank 5001. Anomie 11:22, 20 September 2013 (UTC)
You should use Special:WantedTemplates for this purpose instead. The special page is currently disabled, but thanks to recent efforts of User:Nemo_bis and WMF's new database engineer Sean Pringle it's going to start being refreshed once again [2]. Matma Rex talk 11:35, 20 September 2013 (UTC)
The WantedTemplates would be great to have again (and the disabled refresh explains why redlinks have gone uncorrected after January). Perhaps Sean Pringle can also fix the edit-conflict overwrites by setting "read-lock" to the page of each edit-SAVE before using diff3.c to merge edited sections. Remind him its a big problem in busy articles or popular talk-pages. -Wikid77 13:24, 20 September 2013 (UTC)
Can't you use Wikipedia:Database reports/Templates transcluded on the most pages/Configuration to run your own search? You can modify the limit there (currently set at 1,000). Fram (talk) 11:42, 20 September 2013 (UTC)
Thanks. I am hoping the re-activated Special:WantedTemplates will be easier for fixing the major redlink templates. -Wikid77 13:24, 20 September 2013 (UTC)

It could be nice to have one for modules - to see the number of transclusions Christian75 (talk) 13:55, 20 September 2013 (UTC)

Good idea, and the module namespace=828 (rather than 10 for template namespace), but I was thinking to state "number of invokes" for modules. We know Module:String has 1.417 million and Module:Citation/CS1 has 2.065 million invokes (400 more per day?). -Wikid77 (talk) 14:59, 20 September 2013 (UTC)
You might find it handy to get a labs account. It only took we a day to get approved. Then you can run your own queries on the replicated database to your heart content.--User:Salix alba (talk): 18:29, 20 September 2013 (UTC)

Odd access issue

Yesterday and today, my ability to use Wikipedia (both from a searching capability and as an editor) was hampered. I would try to open the site on my browser (IE10) and pages wouldn't load, I'd see that little indicator that a page was loading but it would never load. On other occasions, a page would load only half-way. Then I'd have a page load and in going to another page, the second page would not load--i.e. when I was editing and chose to save, or if I was at one article and navigated to another. Now when I was editing a page, and I saved my work, the next page wouldn't load--I'd get only a white screen--but my emendations to an article would save.

I've never had this problem before. Not once in 10 years of participation.

Now, as far as loading non-Wikipedia pages, I haven't had a single problem in browsing/access all day--everything loaded well, quickly, as it usually does. This is an issue I've experienced in the past 24 hours exclusive only to my use of Wikipedia.

Was this a server problem? a cookie problem? I had no other problems, so I'm leaning to thinking the problem wasn't on my end.

Please advise. BTW, I'm smart, but I'm not computerwonk smart, so despite being semi-literate, explain it to me as if I was an illiterate 3rd grader.--ColonelHenry (talk) 12:09, 20 September 2013 (UTC)

  • Weekly MediaWiki updates garble browser cache files: For the past several months, there have been weekly changes to the MediaWiki software which displays the Wikipedia pages and edit-mode screens. Also, there are now numerous CSS-class files (hundreds and thousands) which must be downloaded to format the browser skin and page styles. If, during a weekly update to MediaWiki, any of those support files change from the stored cache for your browser, then a lock-up (especially with various IE browsers) can be expected until about Friday each week. The proof of the underlying changes can be shown by re-triggered reformats of prior cached pages in a browser. Of course, Google or other top websites do not rewrite their major software every week, and those websites do not lock-up mid-week. So anyway, the easiest fix, for lock-up with WP screens, is to clear/purge the cache of your browser (Internet Options "Delete Files") between Tuesday-Thursday each week before viewing WP pages. Also plan some extra time for the lock-ups to occur, so don't expect a quick "2-minute edit" to a page on Wednesday, as might be the case on Friday evening when MediaWiki updates are stopped for the weekend. Otherwise, remember we are all coping with these bizarre "user-interfere" changes (every week), but the overall goal is working to expand WP's impressive collection of articles. -Wikid77 (talk) 13:53, 20 September 2013 (UTC)
    • This is patently false: you're spreading fear, uncertainty and doubt. Please stop. You are wrong, you don't know how the software works, yet you act as if you were the resident expert on everything. When the updates happen they do not behave like you described (ResourceLoader solves these issues), there is not such thing as "CSS-class files", they can not cause the issues described unless someone broke the code completely (the "lock-ups" are your sick invention), and Google does deploy new code continuously. You're wrong on literally everything you wrote other than the fact that there was an update on Thursday. Matma Rex talk 18:38, 20 September 2013 (UTC)
@Matma Rex: Wow, I am sorry you are so disturbed (please try to read wp:NPA and find a not-so "sick invention" for why civility matters). I have travelled over 500 mi (805 km) to different sites to confirm how Wikipedia locks up on different browsers in different cities. I am sorry you cannot accept that reality. People who complain of lock-ups here are not inventing hallucinations. Perhaps someone has time to explain the CSS class files in the browser cache, and how there are hundreds of CSS classes now. Meanwhile, please calm down, and get some perspective. You have gone from seeming helpful to seeming like ... you do the math.  [...how's that answer for pretending to be shocked...] All joking aside, I don't think the prank to claim there are "no CSS-class files" will fool readers here, and I do think that over-the-top denials of browser lockups are no longer a "cool joke" because too many people come here to earnestly beg for help to get their browsers running again. Perhaps if today were April 1st, then people might see the denial of CSS and lockups as a wry comment, but otherwise, a big joke requires an equally over-the-top response to counter the joke... or not. ;-) Wikid77 (talk) 21:27/23:21, 20 September 2013 (UTC)
I am sorry, I've run out of patience. Maybe someone else will find enough to talk to you. https://www.youtube.com/watch?v=5hfYJsQAhl0 Matma Rex talk 21:42, 20 September 2013 (UTC)
And I will walk 500 miles. And I will walk 500 more... ^demon[omg plz] 22:50, 20 September 2013 (UTC)
Good, and I'll show you the browsers in each city's library, hospital or hotel Internet desk, as they lock-up!! -Wikid77 (talk) 23:21, 20 September 2013 (UTC)

@Wikid77: - Thank you for your explanation, surprisingly I understood it more than I expected. I did happen to clear my browser cache early on in the process twice and it had no effect. Still a little shocked that I've never seen that happen in 10 years until this week. --ColonelHenry (talk) 03:10, 21 September 2013 (UTC)

  • Try to stop screens, clear cache + restart browser: I almost forget another part of the problem seems to affect the status of the browser session, so others have noted to also restart the browser. For example, I have found when I have a pending secure-access to another webpage, I have to stop that window, and only then clearing the cache will release the lock-up. Beyond that, then the final step is to restart browser. So in recap, the 3 steps:
1) stop button on pending window, 2) clear cache, 3) restart browser.
The scenario I sense is that the pending, stuck windows are retaining invalid cache files, which cannot be deleted until the pending windows are stopped/closed first, then clear cache, and then restart browser. If that does not work, next time, then return here, and some IE10 experts might know about other issues to watch. Even some of the newest browsers have incompatible features which do not work well with Wikipedia, which surprised me, because I imagined the newer browsers as being "standard reliable" but not so. I guess it's like the warning J.P. Morgan received from his mother-in-law, "Maiden voyages are too uncomfortable... things go wrong" and he did not board Titanic after his luggage went aboard. Instead here, the "penultimate" browsers seem safer, as one version back from the newest browsers, as a general rule. -Wikid77 04:41, 21 September 2013 (UTC)

New database reports

There are a number of suggestions for new database reports sitting unanswered at the bottom of Wikipedia talk:Database reports. Is anyone able to get any of these up and running? I would be particularly interested in the request to add Lua modules to Wikipedia:Database reports/Templates transcluded on the most pages, and my request to have a new report of fully protected templates and modules that are transcluded on a small number of pages. — Mr. Stradivarius ♪ talk ♪ 15:11, 20 September 2013 (UTC)

I think that we need to hold off setting up new reports, or adding features to existing reports, until the present Toolserver/WMF Labs situation is resolved. Labs is significantly slower than Toolserver, so any further reports/features on Labs will slow down those that are already there. Labs is also known to have incomplete data: X!'s Edit Counter is still not showing deleted edits, so what else is missing? On the other hand, Labs seems not to suffer from the reliability problems that have plagued Toolserver over the last year. --Redrose64 (talk) 18:58, 20 September 2013 (UTC)
I'm not sure where you're getting "slower" since the databases are faster by at least an order of magnitude, but the "missing information" you're referring to is information that should have never been made available to begin with on the toolserver. That said, we are in the process of making available a redacted list of deleted edits – but that's an exception. The tool labs isn't intended as a method to get information that isn't already public. — MPelletier (WMF) (talk) 20:10, 20 September 2013 (UTC)
On behalf of Betacommand, he says he can make these reports for you, but they won't be on the wiki. —  HELLKNOWZ  ▎TALK 19:07, 20 September 2013 (UTC)
Thanks for the offer Betacommand. :) If you could code up just the report of fully protected templates and modules transcluded on few pages, that would be fantastic. I'm thinking the report should list fully-protected templates and fully-protected modules with a transclusion count of less than 10,000, in order of transclusion count (low to high). Although feel free to tweak those parameters if you think something else would be more sensible. The other reports can wait until they can be added on-wiki, and Legoktm has sorted out the other one I was interested in below. — Mr. Stradivarius ♪ talk ♪ 23:26, 20 September 2013 (UTC)
Actually, hold that thought - it turns out we already have it. I missed it because it was listed under "protections" and not "templates". It was last run in February though, so it could do with an update. — Mr. Stradivarius ♪ talk ♪ 23:44, 20 September 2013 (UTC)
@Mr. Stradivarius:: [5] should have enabled it for the module namespace, I've queued another run but it might take up to 2 hours to run... Legoktm (talk) 22:59, 20 September 2013 (UTC)
Thank you! Don't worry about it taking two hours - I'm used to updates coming every month or so. :) — Mr. Stradivarius ♪ talk ♪ 23:26, 20 September 2013 (UTC)

Visual Editor Reference Dialog improvement - design mockup for comments

The design team is working on improvements to the VisualEditor Reference Dialog. We would appreciate any feedback! Check it out here on mediawiki.org at VisualEditor Reference Dialog. --KHammerstein (WMF) (talk) 19:30, 20 September 2013 (UTC)

Image Error

At Battle of Jassini, the image is not being displayed. If the 300px requirement is removed the image displays correctly but is too large. Can anyone fix this? Ryan Vesey 03:04, 21 September 2013 (UTC)

This issue has been fixed. Ryan Vesey 03:52, 21 September 2013 (UTC)

The bot that checks for bad usernames has stopped running.

search failure / glitch / I'm confused

AN/I archive 799 has the phrase Senators Dodd and Lieberman , yet searching for the phrase [6] returns 0 results. (Last edit to 799 was 10 June.) The search query comes from {{Administrators' noticeboard navbox/Search}} NE Ent 11:36, 16 September 2013 (UTC)

I have noticed before that the search facility doesn't work correctly with archives over a certain size (can't remember if it's 256 KB or 512 KB). The thread in question is towards the end of the archive page, so it might be past the size limit. --Redrose64 (talk) 13:35, 16 September 2013 (UTC)
I'm understanding that as a per page limit? -- so the instructions for the both should be adjusted for a smaller limit? NE Ent 21:03, 16 September 2013 (UTC)

The search backend is changing soon on Wikimedia wikis, by the way. There are notes somewhere... mw:CirrusSearch maybe. --MZMcBride (talk) 04:32, 22 September 2013 (UTC)

Arabic fonts

A few months back (can't remember exactly when), there was a change in the font used for Arabic in Wikimedia projects. The "old" font was a professional-looking, easy-to-read one similar to the ones used in most major Arabic news outlets (e.g. Al-Jazeera). The new one is a more floral, "handwritten" style that greatly slows reading (particularly for non-native readers) and looks exceedingly sloppy (such as when it defies table cells). Arabic Wikipedia used it for a time, but seems to have switched back to the older, cleaner font recently

Why was this change effected and is there a way of turning it off or circumventing it? ~~ Lothar von Richthofen (talk) 18:07, 17 September 2013 (UTC)

See https://www.mediawiki.org/wiki/Universal_Language_Selector/FAQ#How_do_you_decide_a_default_font_for_a_language_or_script.3F and https://www.mediawiki.org/wiki/Universal_Language_Selector/FAQ#Can_I_disable_the_default_font_that_ULS_has_chosen_for_my_language.3F --AKlapper (WMF) (talk) 19:34, 17 September 2013 (UTC)
Fixed it, thanks! ~~ Lothar von Richthofen (talk) 21:13, 17 September 2013 (UTC)
I think it still needs fixing. I don't believe it's reasonable to expect all users to follow the steps AKlapper (WMF) has helpfully suggested. That table looks like crap; it's broken, and needs to be mended. If the old font worked there, why not go back to it? I hadn't noticed the table problem, but have been wondering for a while why I was finding it hard to read Arabic running text, and until reading this had attributed it to worsening eyesight; the old font was definitely more readable. Justlettersandnumbers (talk) 11:53, 18 September 2013 (UTC)
Please feel free to create a ticket in the 'Bugzilla' bug tracker under product "MediaWiki extensions" and component "UniversalLanguageSelector" by following the instructions How to report a bug. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 15:08, 18 September 2013 (UTC)
Alright, I've added a comment (comment 4) to bugzilla:53957 because it might be the same problem. --AKlapper (WMF) (talk) 11:26, 19 September 2013 (UTC)
We (the Language engineering team) are considering a change in the Arabic font that is provided with the ULS. Can't promise anything right now, but stuff may change soon, so that local fixes wouldn't be needed. --Amir E. Aharoni (talk) 18:04, 21 September 2013 (UTC)

Huge one day surge in article reads: wikibug or user anomaly?

Can anyone explain why the readership of Mount Hood climbing accidents jumped upward dramatically for a day last week? (See stats) The article's usual level of access is 50–200 per day, but it was 22,639 on Friday September 13. I have asked around and searched in earnest. There appears to be nothing related in the media and as far as the Oregon community knows, there is no known cause. —EncMstr (talk) 21:37, 20 September 2013 (UTC)

Huge pageview spikes sometimes occur for no obvious reason, and several articles get *insane* levels of pageviews every day, for no obvious reason. Of course, there are cases of pageview spikes of news events broadcast by major news media, such as a blockbuster movie film premiere or a celebrity death. As far as I know, there are no reported cases of wikibugs in the pageview-spike cases, only the drop to low pageview counts when "https" requests were mistakenly omitted from the data logging (see essay: "wp:Google https links"). I guess we need an essay "wp:Pageview spikes" to better explain all the issues, where many people often ask about similar spikes with no obvious explanation. -Wikid77 01:35, 21 September 2013 (UTC)
I dug some more and grabbed the raw page read statistics. 22,543 reads occurred during one hour, which is the granularity of the raw data. I wouldn't be surprised if they occurred in a shorter timeframe, maybe some kind of bot storm. Is there a log of DoS storms, or maybe some other indication of server load?
date time reads bytes transferred
2013-09-13T00:00:00 1 32109
2013-09-13T02:00:01 1 32097
2013-09-13T03:00:00 3 96330
2013-09-13T04:00:00 3 96302
2013-09-13T05:00:09 2 32476
2013-09-13T06:00:00 3 96324
2013-09-13T07:00:00 2 64216
2013-09-13T10:00:00 1 32250
2013-09-13T11:00:03 22543 726638824
2013-09-13T12:00:02 1 32244
2013-09-13T13:00:00 2 183016
2013-09-13T14:00:00 3 334183
2013-09-13T15:00:00 3 64655
2013-09-13T16:00:01 8 256872
2013-09-13T17:00:01 7 192952
2013-09-13T18:00:07 13 417553
2013-09-13T19:00:00 22 831983
2013-09-13T20:00:00 4 128436
2013-09-13T21:00:01 16 513886
2013-09-13T23:00:11 4 64793
EncMstr (talk) 17:07, 21 September 2013 (UTC)

Commons having issues

A heads-up, apparently all of a sudden Commons is having issues where newly uploaded (and some older...) files are throwing up bad-filename, no-thumbnail-for-you errors, even on the main preview image, and refuse to load on en.wiki pages too - I've pinged the village pump there but thought I'd drop a note here. - The Bushranger One ping only 02:11, 21 September 2013 (UTC)

The thumbnails renderer have been broken on Sep 21 from 1:38am until 3:16am. Was related to some mess with thumb.php and thumb_handler.php. Hashar (talk) 04:49, 22 September 2013 (UTC)

Neither Archive bot will archive my user talk page

I had been using MiszaBot to archive my talk page, however around August 6, it just stopped doing so. (That was before the recent problems) Recently, I tried switching to Cluebot, which is now pasting the contents of my talk page into the archive, but is not removing them from the talk page. Can anyone figure out what I have done to anger the Archive Bot Cabal? Monty845 03:56, 21 September 2013 (UTC)

User:ClueBot seems to be messing up intermittently at several user pages. A cursory look showed these two archive additions were missing accompanying talk page subtractions: [7], [8]. Common to those and your page were User:SuggestBot entries within and surrounding the archived discussions; whether that has something to do with it, I don't exactly know. If you just want to fix it, I would manually archive all your talk page posts from bots. I have a feeling that will get it working again. If you want to get to the bottom of it, perhaps someone smarter than me has an explanation. equazcion (talk) 04:42, 21 Sep 2013 (UTC)
I don't know if ClueBot III uses a similar mechanism as the MiszaBot family, but there have been occasions (see the archives of User talk:Misza13) when the bot has copied sections to the archive, but has not deleted them from the main talk page. Several times, this was associated with an archive page that, prior to copying the thread, was of a size that already exceeded the |maxarchivesize= configuration item. The solution was to remove the duplicated threads, and manually adjust the |counter= configuration item to the next unused number. The next time the bot ran, it created the new archive page, copied the threads, and deleted them from the main talk page. --Redrose64 (talk) 12:08, 21 September 2013 (UTC)

Twinkle won't leave delete template

Hello again! I wanted to delete this old Afc draft (housekeeping) using Twinkle because another copy of the article was accepted and is in mainspace, (The histories can't be merged because there is parallel development.) However, there's a comment from another editor which has a deleted template encased in NOWIKI commands. Twinkle picks this up and refuses to leave the delete template. I know that I could just remove the comment, but I thought that I should report this in case it's unintended. —Anne Delong (talk) 13:23, 21 September 2013 (UTC)

Pywikipedia broken

About a week after Wikipedia was converted to https-only for login/editing, my pywikipedia installation has refused to run scripts, with the following sort of error messages "WARNING: Token not found on wikipedia:en. You will not be able to edit any page. Received incomplete XML data. Sleeping for 30 seconds..." I have unsuccessfully attempted to resolve the problem by using SVN to update to the latest version of pywikipedia. Any assistance regarding this issue would be appreciated. Thank you. DavidLeighEllis (talk) 20:21, 21 September 2013 (UTC)

@DavidLeighEllis: Pywikibot moved to git, please see mw:Manual:Pywikibot/Gerrit on how to upgrade. Legoktm (talk) 21:43, 21 September 2013 (UTC)

Is anyone else getting this? I'm getting enormous blank spaces after the footer on some pages, and I've no idea why. Running Chrome and I've tried disabling every extension, hard-refreshing and restarting Chrome -- nothing's working. It's very weird. Happening on Costa Concordia disaster, for example -- the page as it should be shows up, but then there's an enormous blank area about 1/3 the size of the entire article after it. Doesn't happen in Firefox, so it's something in Chrome, but I can't work out what. Anyone have any ideas? As a sidenote, because it might be related, who knows: Wikipedia seems to be forcing SSL on me, and I can't work out why... Again, Firefox doesn't, but using https manually on Firefox doesn't add this enormous whitespace either. Running Chrome 29.0.1547.76 m on Win7. Buttons to Push Buttons (talk | contribs) 23:55, 18 September 2013 (UTC)

It's a Chrome issue having to do with long {{reflist}} columns. It's being looked into here. equazcion (talk) 23:58, 18 Sep 2013 (UTC)
Aha, thanks very much. Did a ctrl+f for "blank" and "whitespace" but neither hit in that section... Cheers. Buttons to Push Buttons (talk | contribs) 00:04, 19 September 2013 (UTC)
Regarding SSL, Wikipedia has forced SSL for logged-in users since 28th August. (This can be disabled in preferences.) Were you logged in on Firefox? If you were logged in, did you last log in using Firefox before 28th August? The force-to-HTTPS behaviour only starts happening (for each browser you use) from the next time you log in after the feature was introduced. – PartTimeGnome (talk | contribs) 21:54, 19 September 2013 (UTC)
Yeah, that's it -- I only use FF when I'm checking if something's wrong with Chrome, and so wasn't logged in. Thanks for the link. Buttons to Push Buttons (talk | contribs) 17:27, 20 September 2013 (UTC)

I think I'm getting the same thing in that, on some articles, a large number of references are invisible despite being correctly formatted. I first noticed on the Bournemouth which I am currently working on but it the same with other articles so I don't think it's anything I've done. I'm not running Chrome, unless it's been sneaked on while I was updating something. How can I find out and disable it?--Ykraps (talk) 07:08, 20 September 2013 (UTC)

Chrome is a browser, not something that might be sneaked on you... which browser are you using? --Redrose64 (talk) 16:30, 20 September 2013 (UTC)
I am afraid that my knowledge of computers is exceptionally limited so I'm not even sure what we're talking about here. I am assuming now that a browser is different to a search engine? If I said Bing was my search engine and Internet Explorer was my browser, would that sound about right?--Ykraps (talk) 17:20, 20 September 2013 (UTC)
Yeah, that's right, IE is your browser and Bing is your search engine. Chrome is an alternate to IE, from Google. Buttons to Push Buttons (talk | contribs) 17:27, 20 September 2013 (UTC)
Since you're using Internet Explorer (IE), a web browser which is known to have certain ... er, differences ... from other browsers, it sometimes helps in resolving problems if we know which version of IE that you're using. Press Alt+H, this should open a small menu near the top of the screen. From that, select "About Internet Explorer" (it's usually the last item). You should get a window containing a logo; that logo may include a number, probably between 7 and 10. If it doesn't, there should be a few rows of text, one of which should begin "Version:" followed by a longer number. This is what we're interested in. --Redrose64 (talk) 19:48, 20 September 2013 (UTC)
It appears to be the latest version of IE, Version 10. I am intrigued by these 'differences'. How does IE differ from other browsers?--Ykraps (talk) 08:25, 21 September 2013 (UTC)
Oh, where to start? Web pages are written using software that generates code such as HTML and CSS that is computer-readable, and to an extent, also human-readable. There are standards documents that describe what is "good" HTML and "good" CSS, which have appeared in several revisions over more than twenty years. Few browser vendors stick rigidly to one of these revisions (otherwise there would be no progress), but have either chosen to ignore portions of the standards, or have added their own extra features (sometimes both). Similarly, web page authors might not adhere rigidly to the standards. This means that a web page written to take advantage of the features of one browser might not work as expected in another. For example, visit NBR 224 and 420 Classes#Notes. In Internet Explorer versions up to 9, there is a single column, which occupies a little less than a quarter of the page width on a screen 1280 pixels wide. But using certain other browsers, such as Google Chrome or Mozilla Firefox, there are four columns here. To complicate things, Microsoft have chosen to provide recent versions of Internet Explorer with a setting known as "quirks mode", which can be used to configure which features the browser exhibits, so depending on that setting, IE 10 may show one column - or several.
What it comes down to is this. If the web page author has performed a calculation for vertical positioning that the browser doesn't understand, the browser may display certain portions of the page too far up the page - or too far down. --Redrose64 (talk) 15:55, 21 September 2013 (UTC)
Okay, I think I understand. Some browsers are better at interpreting some codes than others, so changing my browser might solve the problem.NBR 224 and 420 Classes#Notes shows as 3 columns with IE 10 by the way.--Ykraps (talk) 15:34, 22 September 2013 (UTC)
Have just downloaded Firefox and things seem okay now.--Ykraps (talk) 16:05, 22 September 2013 (UTC)

how does td style work in wikipedia?

how does td style work in wikipedia?

span works on both wikipedia and on other wikis, but td does not.

Where is td style defined on wikipedia? Is it at Mediawiki:common.css maybe ?

Thank you.

Example:

<td style="background:#a3b1bf">test</td> -- works only on wikipedia, not other wikis
<span style="background:#a3b1bf">test</span> -- works on wikipedia, and all other wikis

Special:Contributions/108.28.6.134 (talk) 05:44, 19 September 2013 (UTC)

You aren't giving enough context, but this sounds like it could be a case of mixing wikitable and htmltable syntax (which only works with Tidy, which Wikipedia uses and many other wikis do not). Does this work on the other wikis in question?
foo bar
foo bar
--Splarka (rant) 07:15, 19 September 2013 (UTC)
108.28.6.134 - regarding your test here, it looks peculiar (with the table cell below the span and the signature) because you've used <td>...</td> in isolation. It only displays predictably if it is properly enclosed in <table><tr>...</tr></table>. I've fixed it. --Redrose64 (talk) 15:11, 19 September 2013 (UTC)
The wiki in question is: http://deadrisingwiki.com
BRILLIANT GUYS! Adding the <table> tags made it work.
Such an easy solution!
User:Splarka - your test works. http://deadrisingwiki.com/wiki/Template_talk:Tab
I will check out Tidy. I thought tidy was for something else, but I will check it out! Thank you!

I get the same thing by adding <table> as I do here.

td style test

Igottheconch (talk) 16:50, 19 September 2013 (UTC)

SOLVED - and fixed the template:tab too. It was a template error. [9] Igottheconch (talk) 17:59, 19 September 2013 (UTC)

The problem with that edit is that it assumes that browser vendors have implemented the border-radius: property. This is not yet part of the formal CSS specification - it is still at Candidate Recommendation stage. Browser vendors are unlikely to fully support it unless it reaches at least the Proposed Recommendation stage; some may wait for the final W3C Recommendation. Until that happens, we have used the {{border-radius}} template, which uses several proprietary properties to achieve something similar - -moz-border-radius: for Mozilla browsers and -webkit-border-radius: for Webkit browsers as well as the proposed border-radius: property. --Redrose64 (talk) 18:41, 19 September 2013 (UTC)
In fairness, whatever its W3C status, virtually all browsers *do* support border-radius these days without need for a proprietary prefix; indeed, most have supported border-radius for yonks (IE9, Firefox 4, Chrome 5) [10] . - Jarry1250 [Vacation needed] 21:55, 22 September 2013 (UTC)

Gadget descriptions in multiple languages

Occasionally I go through my accounts on "all" the different WM wikis (e.g., Belarusian Wikisource, Vietnamese Wikivoyage...) and update/standardize my preferences. (Just waiting for central preferences to happen.) The hardest part to deal with (for me, as someone who reads only English well) is the Gadgets tab, since the descriptions there are not provided in the user's chosen language but only in the local language of the wiki (example: fr:Special:Gadgets). Two questions about this:

  1. I assume there is currently no easy technical solution to providing gadget descriptions in multiple languages, since it hasn't happened yet. Has there been discussion about this anywhere? (I didn't find anything searching Bugzilla, but then I rarely do.)
  2. Is there any good reason the English Wikipedia is not providing links to MediaWiki:Gadgets-definition and Special:Gadgets from Special:Preferences#mw-prefsection-gadgets, like every other WM wiki seems to? I find these two other pages very useful in wikis in which I don't understand the language at all (MW:G-d shows the gadget names, which are sometimes more understandable than the descriptions; and S:G can be translated at Google Translate, whereas S:P cannot).

- dcljr (talk) 20:53, 20 September 2013 (UTC)

I think a solution exists and is easy, it's just that no one cares to use it – for each gadget description page such as MediaWiki:Gadget-Navigation popups create subpages with translations for each language – MediaWiki:Gadget-Navigation popups/de, MediaWiki:Gadget-Navigation popups/es, MediaWiki:Gadget-Navigation popups/ru etc. Matma Rex talk 21:50, 20 September 2013 (UTC)
Commons does this with most gadgets, such as HotCat. AFAIK the only translated gadget on English Wikipedia is MediaWiki:Gadget-popups.js/de. --Redrose64 (talk) 22:19, 20 September 2013 (UTC)
m:Wikimedia Scripts proposal (or existing translatewiki.net) could solve this by providing a central translation interface for gadgets and gadget-descriptions. πr2 (tc) 00:57, 21 September 2013 (UTC)
To demonstrate that gadget descriptions on en.wp are translatable, I've created MediaWiki:Gadget-HotCat/de. To see the effect, go to Preferences and set your language to "de - Deutsch"; save it, and then go to Preferences → Gadgets (which will now be titled "Helferlein"), and have a look at the fifth item under "Editing". --Redrose64 (talk) 09:49, 21 September 2013 (UTC)
It can be seen with uselang=de without changing preferences. PrimeHunter (talk) 10:55, 21 September 2013 (UTC)
This is true, but do you want to translate the gadget messages of all WM wikis? That would solve the problem here. πr2 (tc) 15:35, 21 September 2013 (UTC)
Personally, I'd be useless as a translator, so no, I don't want to. I didn't even translate MediaWiki:Gadget-HotCat/de - I knew that the HotCat gadget on en.wp is, in most respects, identical to that on Commons, so I merely copied the German description from Commons and altered the second link to a suitable place on en.wp This approach will work for HotCat descriptions in several other languages, but won't work for every gadget, since a lot of en.wp gadgets are not found on commons (compare MediaWiki:Gadgets-definition with commons:MediaWiki:Gadgets-definition); or if they are, they differ in some significant manner. When Commons doesn't have a translation (for example, none of the gadgets on Commons has a Welsh-language description), we could go to the Wikipedia of that other language and see if it has the gadget installed. Wicipedia Cymraeg has no gadgets to copy... --Redrose64 (talk) 17:21, 21 September 2013 (UTC)
Regarding point 2: The top of Special:Preferences#mw-prefsection-gadgets displays MediaWiki:Gadgets-prefstext. The English Wikipedia has customized the message and made a link to Wikipedia:Gadget but not MediaWiki:Gadgets-definition and Special:Gadgets which are linked from Wikipedia:Gadget. I don't know whether it was a deliberate decision to omit direct links from MediaWiki:Gadgets-prefstext but you can suggest a change. The MediaWiki default for English can currently be seen at MediaWiki:Gadgets-prefstext/en-gb which hasn't been customized. MediaWiki defaults must work at all wikis so they can only link to pages which will always exist. PrimeHunter (talk) 11:18, 21 September 2013 (UTC)
I've restored the links. I often find myself looking for those, or typing them in manually. This should making maintenance much easier. Edokter (talk) — 11:56, 21 September 2013 (UTC)
  • Gadget language files protected against linguists: If we had unprotected language versions, then I think more people might translate "MediaWiki:Gadget-popups.js/de" into:
We have several users who are linguists, and they might help with any troublesome phrases. Perhaps the pages could be created in a gadget-sandbox area, and then installed when ready. -Wikid77 (talk) 21:18, 22 September 2013 (UTC)
Why change established practice? Pop an {{editprotected}} request at the relevant talk page for the default language - such as MediaWiki talk:Gadget-popups.js - stating the page that is to be created or edited (this would go in the first positional param, e.g {{editprotected|MediaWiki:Gadget-popups.js/de}}), and follow that with the text that is to be added or changed. See for example MediaWiki talk:Gadget-teahouse/content.js#Edit Request 26 Aug 2013. --Redrose64 (talk) 21:48, 22 September 2013 (UTC)
Resolved

I was looking at the source of {{In the news}} and happened to notice that the "Submit an Edit Request" link was broken. Apparently, something involving redirects and modules broke it. Screenshot to see the error. I'm not sure exactly how to fix this off the top of my head or if it can even be fixed. Technical 13 (talk) 17:37, 21 September 2013 (UTC)

PS This refers to the link that appears in the interface when viewing the source of a protected template, not a link in the code of {{In the news}} itself. equazcion (talk) 17:47, 21 Sep 2013 (UTC)
The redirect at Template talk:In the news has a colon before the space - "#REDIRECT: [[Wikipedia talk:In the news]]" - which doesn't match what's in the line starting with "local redirect" in Module:Redirect. Peter James (talk) 19:43, 21 September 2013 (UTC)
I removed it. Legoktm (talk) 21:45, 21 September 2013 (UTC)
Apparently it was added by Gfoley4 (talk · contribs). --Redrose64 (talk) 13:26, 22 September 2013 (UTC)
Sorry for any trouble... GFOLEY FOUR!17:19, 22 September 2013 (UTC)

Notification on my User & Talk pages -- post personalised messages of thanks as appropriate

I have been receiving messages of "Thanks" recently from various editors following some revisions that I have made to articles of a common interest. How do I activate this feature for my own use?
— | Gareth Griffith-Jones | The Welsh Buzzard |21:10, 21 September 2013 (UTC)

Gareth Griffith-Jones, if you look at a page history (such as the history of this page, you will see that at the end of each line there are links for (undo | thank).
Similarly, if you look at a diff such as one, you will see a "thank" link at the top right of the heading for the newer version.
Just click those links if you want to thank the editor. --BrownHairedGirl (talk) • (contribs) 21:39, 21 September 2013 (UTC)
I guess you refer to Wikipedia:Notifications/Thanks. PrimeHunter (talk) 21:32, 21 September 2013 (UTC)
Thanks for the link to Wikipedia:Notifications/Thanks. I followed the reversal of opting-out described there and I can now *thank* other editors. To check that it works, I *thanked* you. Did you receive it? Cheers!
— | Gareth Griffith-Jones | The Welsh Buzzard |21:43, 21 September 2013 (UTC)
Yes, I received it. It's also logged at [11]. PrimeHunter (talk) 23:59, 21 September 2013 (UTC)
That is kind of you to lead me to that log. It shows the only time I used the function before I "opted-out". Cheers!
— | Gareth Griffith-Jones | The Welsh Buzzard |15:55, 22 September 2013 (UTC)

accessdate= requires |url= (help)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Ref 5 here. I have just read the news in today's The Times of India (hardcopy newspaper, not in web). For some reason, I can not find the web copy of the news — most probably it has not been crawled by Google. Just 1-2 day(s) ago, I cited an offline newspaper source. These accessdate= requires |url= (help) are annoying. Those are not available. The Toi Source here may be available in next 1-2 days (I mean when Google will crawl the page), but, for my other offline sources, URL etc will never will available. --TitoDutta 16:59, 22 September 2013 (UTC)

Then don't give an accessdate. Accessdate is only relevant if you read an article online, it means that on the Accessdate, the article existed in the form that you read it. Ryan Vesey 17:01, 22 September 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Space, the Wikipedia frontier

This topic is not to do with Star Trek. Windows used to end where the text for when the page was last modified. However, I am finding, at least when using Chrome, there is a whole page's worth of space underneath the article end. Is this due to technical limitations? Simply south...... cooking letters for just 7 years 19:03, 22 September 2013 (UTC)

See "#Scrolling past the bottom of the page..." above. – Jonesey95 (talk) 19:54, 22 September 2013 (UTC)

Log-in/Log-out, Skins problem

Now somebody has really done it with the dubious animation in the upper right corner. Cologne Blue skin not showing, notice appears "CENTRAL LOGIN. You are centrally logged in as Carrite. Reload the page to apply your user settings." Which doesn't work, of course. Log-out fails. Ridiculous. 24.20.128.148 (talk) 16:22, 20 September 2013 (UTC)

When I get this message, I wait a few seconds then hard-refresh the page (it's Ctrl+F5 in Firefox). That usually fixes it. --Redrose64 (talk) 18:59, 20 September 2013 (UTC)
I believe loading any page would apply settings, not just reloading the previous one, but I may be wrong. πr2 (tc) 02:14, 21 September 2013 (UTC)
Would like to know what "it doesn't work" exactly means. --AKlapper (WMF) (talk) 17:22, 22 September 2013 (UTC)
Aklapper, small guess, the JS that does the login redressing only works for Vector and Monobook. And it seems there is a problem that every time you visit a http address while logged in over https, you get the 'central login, you are centrally logged in as' notification for every page view. I'm seeing this as well right now. —TheDJ (talkcontribs) 09:52, 23 September 2013 (UTC)
Thanks! I've filed this as bugzilla:54513. --AKlapper (WMF) (talk) 16:29, 24 September 2013 (UTC)

Analysing category overlap

Resolved

I have been busy diffusing Category:British actors to its sub-categories, and my subjective impression has been that there is huge overlap between the categories for the various media: film, television, stage, radio, video game, and voice.

If that impression is correct, it clashes with the long-standing principle at WP:OC#OVERLAPPING. So I would start an RFC on whether we should reconsider categorisng actors in this way.

However, before doing that, I want to try to measure the extent of the overlap of media in the ~11,000 articles. I think that the figures which would be useful are:

  1. number of articles in only one media category (i.e one of the subcats of Category:British actors by medium)
  2. number of articles in any two media categories
  3. number of articles in any three media categories
  4. number of articles in any four media categories

Any suggestions on how I might go about getting those figures? I had considered trying CatScan2, but can't see any way of making it do this. --BrownHairedGirl (talk) • (contribs) 21:28, 21 September 2013 (UTC)

Adding the list of categories, one per line, without namespace (copying from the category page doesn't work; maybe it contains hidden formatting characters), setting "depth" to 4 (which seemed to be enough here) and using "at least" going from 1 to 4 results in data that may be what you are looking for - I don't know how accurate it is. I've used the six "media" subcategories of Category:British actors by medium, excluding nationalities and the stub category. If this is correct, the majority are in more than one category:
  • 9969 in at least 1 category
  • 5384 in at least 2
  • 2008 in at least 3
  • 503 in at least 4
Of those, 106 are in at least 5, of which 2 (Brian Blessed and Daniel Craig) are in all 6. Peter James (talk) 12:11, 22 September 2013 (UTC)
One thing to look out for is categories within more than one parent category (which is usually acceptable overlap, and would probably produce article overlap). There are none within the categories I used, but adding the nationalities finds some. Peter James (talk) 12:50, 22 September 2013 (UTC)
@Peter James:, thank you very much! That's really useful data. It partly confirms my hunch, tho it doesn't look as bad as I thought.
I would love to be able to try it myself, but I am not quite sure that I would manage to replicate it. Could you be kind enough to post a link to one of the completed search forms you used? The links are on the results page at the bottom of the search box, labelled
Link to a pre-filled form for the query you just ran.
Thanks! --BrownHairedGirl (talk) • (contribs) 01:48, 23 September 2013 (UTC)
The page has two links: with and without auto-run for articles in at least 1 of the six categories. Peter James (talk) 18:03, 23 September 2013 (UTC)
Bless you, Peter James. That's great! --BrownHairedGirl (talk) • (contribs) 20:20, 23 September 2013 (UTC)

File Upload Wizard not working properly

Resolved

After uploading, the final page displayed to users has the following message:

   Your file has been uploaded successfully and can now be found here:
   File:Example.jpg

Instead of "Example.jpg" there should appear the new file name. This final page has been modified recently and apparently the last programmer introduced this bug. It is serious, as the user may not know how to locate the file they just uploaded. Can someone please look into it? —Prhartcom (talk) 02:59, 22 September 2013 (UTC)

Fixed, I think. There was something about the server settings that had broken the originally intended notification mechanism for a while, but apparently this is now working again. Fut.Perf. 23:14, 22 September 2013 (UTC)
No, I just tried it, and it's still not working. —Prhartcom (talk) 04:11, 23 September 2013 (UTC)
I took a look at the HTML source, I know that is not the code driving the wizard, but I see something that may help: "Example.jpg" appears throughout, even in places where I saw that it was substituted with the real filename. If it helps, I see:
   Once uploading is completed, you will find your new file at this link::
   <span id="fuwSuccessLink"><b><a href="/wiki/File:Example.jpg" title="File:Example.jpg">File:Example.jpg</a></b></span>

and then I see:

   Your file has been uploaded successfully and can now be found here:
   <span id="fuwSuccessLink2"><b><a href="/wiki/File:Example.jpg" title="File:Example.jpg">File:Example.jpg</a></b></span>

For the user experience, he sees the first example above substituted with his real filename but the second example above has failed to substitute. Could it be that the id="fuwSuccessLink" variable is correctly populated but the id="fuwSuccessLink2" is not? —Prhartcom (talk) 12:12, 23 September 2013 (UTC)

Cleared cache and the fix now works. —Prhartcom (talk) 13:05, 23 September 2013 (UTC)

What adds the [ ] in collapsible?

Hello! Hope you are having a great weekend!

I am interested in what section of the coding in MediaWiki:Common.js or MediaWiki:Common.css creates the [ ] in Collapsible elements?

If someone wanted to change [ ] to { } for example, or delete it all together, where can that be done?

I notice:

var collapseCaption = 'hide'

var expandCaption = 'show';

Controls the words "hide" and "show".

THANK YOU! Igottheconch (talk) 11:34, 22 September 2013 (UTC)

<span class="collapseButton">
    [
    <a id="collapseButton0" href="#">
        hide
    </a>
    ]
</span>
This means that it wasn't added in any .css using :before or :after. There is some code in MediaWiki:Common.js that creates these links and it looks like:
/* set up the words in your language */
var NavigationBarHide = '[' + collapseCaption + ']';
var NavigationBarShow = '[' + expandCaption + ']';
If you want to change them here on Wikipedia you would have to add something like the following to your common.js:
/* Change collapse links from [ * ] to { * } */
var currCollapseButton = $( '.collapseButton' ).html();
currCollapseButton = currCollapseButton.substring( 1, currCollapseButton.length - 1 );
$( '.collapseButton' ).html( "{" + currCollapseButton + "}" );
Let me know if this works for you (I'm not going to try it myself as it's just too insignificant for me to care about). If it doesn't, then I'll throw it in my sandbox skin.js and tweak it to work for you. Good luck! Technical 13 (talk) 12:56, 22 September 2013 (UTC)
  • Oh yeah, to make the [ ] just completely go away, you could use:
/* Change collapse links from [ * ] to * */
var currCollapseButton = $( '.collapseButton' ).html();
$( '.collapseButton' ).html( currCollapseButton.substring( 1, currCollapseButton.length - 1 ) );
Almost forgot you asked about that option... Technical 13 (talk) 13:11, 22 September 2013 (UTC)
According to mw:Manual:Collapsible elements, there are three types of collapsible elements. NavFrame (with div class="NavHead", and the only type with brackets as part of the link) uses:
var navigationBarHide = '[' + collapseCaption + ']';
var navigationBarShow = '[' + expandCaption + ']';
Collapsible tables (with span class="collapseButton" contains:
Button.appendChild( document.createTextNode( '[' ) );
Button.appendChild( ButtonLink );
Button.appendChild( document.createTextNode( ']' ) );
and there's jQuery.makeCollapsible, with span class="mw-collapsible-toggle mw-collapsible-toggle-expanded", but that doesn't appear to be in Common.js - it's part of ResourceLoader - and has "Collapse" and "Expand" buttons. Peter James (talk) 14:35, 22 September 2013 (UTC)
Thank you Thank you Thank you Technical 13. I appreciate it so much!
User:Igottheconch/Common.js
User:Igottheconch/Common.css
Attempt to try it:
User talk:Igottheconch/Common.js
It doesn't work :(
Any suggestions?
Thanks Peter :) Igottheconch (talk) 14:36, 22 September 2013 (UTC)
This is exciting!
Progress!
[Show] becomes either:
{Show}
or
Show
But the collapsible table no longer works.
User talk:Igottheconch/common.js
Thanks Technical 13! Making progress!
Igottheconch (talk) 00:04, 23 September 2013 (UTC)
Peter James how would I apply what you wrote? I tried to replace CollapseButton with NavToggle and it didn't work :/ Igottheconch (talk) 00:09, 23 September 2013 (UTC)
I don't know how to make the links work with changed tags. The NavToggle option is only for a different type of collapsing box; the Wikipedia:NavFrame page has examples of both. The collapse still doesn't work, although with NavFrame boxes the IDs appear to stay correct so maybe that's not the cause of the problem. Peter James (talk) 18:12, 23 September 2013 (UTC)

How to search for � (white question mark inside black diamond) in order to fix them?

I sometimes encounter the "�" character when I am cleaning up citations and other text. On my computer (Firefox 23 for Mac), it displays as a white question mark inside of a black diamond. As far as I can tell, it is inserted in place of a character that cannot be rendered and should be replaced by a regular character of some sort.

I would like to search for these characters in order to fix them in articles, but when I paste that character into WP's search, I get an error message that says "An error has occurred while searching: The search backend returned an error:", followed by nothing (i.e. no error text from the search back end).

Does anyone know of a way to search for these characters so that they can be fixed? Or, alternatively, are they indicative of a rendering problem on my computer?

To see an example of one of these, see this diff. – Jonesey95 (talk) 17:16, 22 September 2013 (UTC)

  • You are referring to the Specials (Unicode block) "U+FFFD � replacement character used to replace an unknown or unrepresentable character" and I am unaware of anyway to currently find these on wiki via a search engine. I suppose, if you were really bored and this "really" bothers you, it would likely be possible to write a bot (would require BAG approval) that will systematically go through all 61,905,695 pages on Wikipedia one at a time and look for the character itself or the associated HTML entity that creates them and adds the pages to a maintenance category that you could then work your way through and fix them. Good luck with that. :) Technical 13 (talk) 17:37, 22 September 2013 (UTC)
Technical 13 (talk) 18:26, 22 September 2013 (UTC)
Nice. So far it's found 320+ articles in 1.5 hours. I'll check back in a while to see how many it finds. A maintenance category might be worth the trouble; some of us WikiGnomes do get a desire to fix small things periodically, bored or not. It would take a while to clear out the category initially, but it wouldn't be much trouble to keep it clear after that. I don't know anything about creating bots yet, so I'll leave that to a fellow Gnome. – Jonesey95 (talk) 20:04, 22 September 2013 (UTC)
It looks like the list topped out at 826 articles. I'm guessing this is a complete scan of the Article namespace; a further scan of the Template namespace would probably turn up a few more. I have fixed about 100 of the articles already. I have pasted the rest of the list as wikilinks at User:Jonesey95/sandbox/diamondcharfix. Until a better list or a category exists, feel free to visit this page, fix the articles in question, and remove items from the list as they are fixed. – Jonesey95 (talk) 04:42, 23 September 2013 (UTC)
Technical 13, are you not aware that Betacommand/Δ is banned? I don't care if you think he's being "helpful", if you keep posting material from him here I will have you up at ANI for assisting block evasion. — Scott talk 22:07, 23 September 2013 (UTC)
You may need to block a couple of others editors too then, including User:Writ Keeper, for this: #Looking for a tool. Just saying. ;) equazcion | 22:12, 23 Sep 2013 (UTC)
Scott, I was not aware of that until a significant amount of time after the post was made. I thank you for assuming good faith in a civil non-threating way. Happy editing! Technical 13 (talk) 22:18, 23 September 2013 (UTC)

Edit history / watchlist side-effect?

Has anyone else noticed that replies to this section in the edit history or the watchlist don't have the little → character at the beginning of the edit summary to allow you to jump right to this section? Happens for me on both IE10 and FF24. Regards, Orange Suede Sofa (talk) 20:21, 22 September 2013 (UTC)

The presence of certain characters in section headings does break section linking. I suspect that � is one such character. --Redrose64 (talk) 20:55, 22 September 2013 (UTC)
Never noticed it before. But I have it (and it works) with Iceweasel 24.0b3-1 (webbrowser based on Firefox) (so its not completly removedChristian75 (talk) 21:00, 22 September 2013 (UTC)

Watchlist message

I just noticed when visiting my watchlist, there is a message stating:

1,552 pages on your watchlist, not counting talk pages. Pages that have been changed since you last visited them are shown in bold.

That is obviously not true for people like me who use a watchlist customization and no longer have the default bold for unvisited changes. This is probably not really an issue for those editors who are able to customize their watchlist and know they use a customization, so I don't know whether something should or could be done about it. -- Toshio Yamaguchi 14:56, 23 September 2013 (UTC)

Interesting. I just visited my watchlist again, and now it says

You have 1,552 pages on your watchlist (excluding talk pages).

Pages that have been changed since you last visited them are shown with a green bullet.

-- Toshio Yamaguchi 15:01, 23 September 2013 (UTC)

The gadget "Display pages on your watchlist that have changed since your last visit in bold" is consistent. It makes the pages bold, and writes that they are bold. If your watchlist customization is made by adding personal code to User:Toshio Yamaguchi/vector.css and not by selecing a preference or importing a maintained script then it's up to yourself whether to add code which describes your customization. See MediaWiki:Gadget-WatchlistChangesBold.js for the gadget code to say the pages are bold. PrimeHunter (talk) 23:09, 23 September 2013 (UTC)
I was just confused because I didn't change anything and suddenly that message appeared. It's gone now, so i suspect this was some kind of glitch on the server side. I don't have the option to display changes in bold checked in my preferences. Thanks. -- Toshio Yamaguchi 07:12, 24 September 2013 (UTC)

Notification of RfC: Should CSD: be an exception to the immunity of pseudo-namespaces to deletion?

There is an ongoing RfC going on at Wikipedia:Requests for comment/CSD pseudo-namespace that anyone visiting this page may be interested in. Technical 13 (talk) 16:39, 23 September 2013 (UTC)

This isn't a technical issue. -- WOSlinker (talk) 17:17, 23 September 2013 (UTC)
It is a gigantic waste of people's time, though, technically. — Lfdder (talk) 18:04, 23 September 2013 (UTC)
It's not ongoing any more; in fact, there is now a MFD to remove the RfC page entirely. -- John Broughton (♫♫) 20:21, 23 September 2013 (UTC)
  • This RfC is being redrafted, and will be reposted. The technical importance of it is that namespaces are a technical entity and I felt there may be technically inclined people interested in the discussion. Technical 13 (talk) 20:31, 23 September 2013 (UTC)

Article wizard

Was just reading an article in my local free paper about how the Wikipedia:Article wizard top tabs dont work. Not sure if its always been like this but the article mentions how complicated the page is. "Article wizard where to next?" - was the title of the article. -- Moxy (talk) 23:55, 23 September 2013 (UTC)

The (1st and 3rd) big blue buttons at the bottom, are the ways to advance through the wizard. I'm not sure how that could be made simpler, or why the newspaper-article-author was confused. –Quiddity (talk) 00:50, 24 September 2013 (UTC)
The next tabs are deliberately grey to signal you cannot select them currently. That's a very common software feature. You have to read each page and make a selection saying your topic is notable, sourced, not advertising and so on, without jumping ahead. The selections are made on big blue buttons that are hard to miss. I wasn't involved in designing the system but it's surely made to try to reduce all the poor creations that will just be declined. If you cannot spare a few minutes to go through the selections then your article would probably be crap, for example a copy-paste of a website advertisement or copyrighted text. Previous tabs are black and clickable so you can go back, for example from Wikipedia:Article wizard/Ready for submission, but we don't want people to start there. Anyway, the place to discuss Wikipedia:Article wizard is Wikipedia talk:Article wizard and not here. PrimeHunter (talk) 01:06, 24 September 2013 (UTC)
Well I know one thing that is missing there, there is no indicator for "next" step. Perhaps adding a > in front or >>> after the button text might help communicate that. —TheDJ (talkcontribs) 09:02, 24 September 2013 (UTC)
There is never a single big blue button. You must select a button to click. I'm not sure it would be an improvement if all of them had > or >>>, but Wikipedia talk:Article wizard is really the place to discuss it. PrimeHunter (talk) 15:54, 24 September 2013 (UTC)

Special:Export encoding

Hi there! When you use Special:Export to get some articles in an xml file, what exact character encoding does that file have? I can't find the answer anywhere! Thanks, Azylber (talk) 04:34, 24 September 2013 (UTC)

from what I can make out, it seems to be UTF8 without BOM Azylber (talk) 06:17, 24 September 2013 (UTC)
UTF-8 is the fallback for XML, so unless specified otherwise it supposed to be UTF-8. —TheDJ (talkcontribs) 08:53, 24 September 2013 (UTC)
Thanks. The XML file doesn't say what it is, so it must be the default then. Azylber (talk) 04:23, 25 September 2013 (UTC)

Has someone mentioned this before? I am finding, every time I log in, no matter the browser, WP still treats me as though I'm logged out. I have to refresh the page in order for everything to be normal. — Preceding unsigned comment added by Simply south (talkcontribs) 14:54, 24 September 2013 (UTC)

Do you have 'clear history at end of session' enabled in your browser - or more simply, are you not ticking the 'remember me for 30 days' box on login? (OK, someone had to ask these - don't care if I get shouted at...) I have clear history, enabled, which gets rid of the cookies I haven't marked as exceptions - like WP, Google (to enforce new window opening), and one or two other sites with preferences stored on cookies. Another one - if you use the 'private window' in Firefox, you'll be treated as not logged in as no cookie setting or reading takes place in 'private'. Peridon (talk) 16:28, 24 September 2013 (UTC)
(edit conflict) When logging in, make sure that "Keep me logged in (for up to 30 days)" is set. If it is, go to Preferences, and make sure that "Remember my login on this browser (for a maximum of 30 days)" is set. --Redrose64 (talk) 16:33, 24 September 2013 (UTC)
Actually, security-wise, if anyone else might possibly have access to your computer (and especially if one has advanced permissions including adminship), you should not tick the "keep me logged in" box, but should actually log in for each session. Consider a password keeper/safe if you prefer not to have to key in your password each time. If you have cookies enabled, the last username you logged in under should be auto-input into the box. Risker (talk) 19:22, 24 September 2013 (UTC)
Yes. Not everytime, but frequently. NE Ent 22:08, 24 September 2013 (UTC)

math code reporting parse errors - sometimes

When I look at Wikipedia:Reference desk/Mathematics#True or False ? I see a bold red message about Failed to parse (unknown error). But if I click to edit the section and preview, even though I haven't changed anything, I don't see it. Something strange is going on with the parser for math. Also, I'm not sure everyone is seeing the error message that I'm seeing. (There are comments from other editors at Wikipedia:Reference desk/Mathematics#True or False ?.) RJFJR (talk) 18:38, 24 September 2013 (UTC)

I saw this error on an article a few weeks ago, and when I either refreshed the page with my browser or edited the page (without changing any of the math coding), the problem went away and the mathematical expression was rendered properly. Seems like an intermittent bug, which may be tricky to track down. – Jonesey95 (talk) 20:27, 24 September 2013 (UTC)
Refreshing (or changing which browser I'm using) seems to help. Thank you. RJFJR (talk) 23:00, 24 September 2013 (UTC)
Yes there has been a number of other reports, two here, the latest at Help talk:Maths and one on the German wiki. It now on bugzilla T56367. My guess is that one of the servers has a faulty texvc.--User:Salix alba (talk): 00:51, 25 September 2013 (UTC)

Section editing

I'm curious. Why does the editing software no longer permit simultaneous editing of different sections of the same page? For instance, see this edit where I inadvertently removed another editor's comment in another section. This has never been a problem in the past, so why is this occurring now? Parsecboy (talk) 17:00, 16 September 2013 (UTC)

Something is currently not right with section editing. bugzilla:53446 was recently opened, but it is likely not limited to high-trafficked articles/pages. You can add a comment there or open up a new bug. Killiondude (talk) 21:41, 16 September 2013 (UTC)
Do you use VisualEditor or the old classic way to edit wikitext manually? --AKlapper (WMF) (talk) 19:30, 17 September 2013 (UTC)
I don't think that VE is enabled on talk pages. --Redrose64 (talk) 20:02, 17 September 2013 (UTC)
  • Overwrite of 1-minute edits has been problem for months or years: Several other users have noted similar problems, sometimes imagining the next editor has deliberately deleted their recent comment, where the prior edit was auto-erased when saving the next edit, within 1 minute after the prior edit. I think it is the "age-old" problem of needing to read-lock the database entry (the page) so that, before an edit can be saved, all other pending edits must wait to only re-read the page after the prior edit has been saved (only 1 session could read the prior revision at a time during the SAVE), then do a diff against the latest read-locked page and auto-merge with the latest prior save, as to not auto-merge by both edits reading the same version of 2 revisions prior as being the revision to merge. Again, unless each SAVE does an exclusive (rapid) read+write lock of the page, then 2 quick edits of a page will both try to merge changes into the same old revision, rather than sequentially readlocking to update once (then unlock), so the 2nd edit is forced to read only after the first edit is saved, to ensure updating the next latest revision in sequence, not merge with 2 revisions back. Note that the exclusive read+write lock would only apply to delay edit-save transactions, and article viewing would not be delayed by the read-lock option. The typical test-and-set logic is needed to control a semaphore to ensure how 2 edits within 1 minute must sequentially wait to read the results of the prior edit-save, before merging new changes, as a 3rd revision applied to the 2nd revision. -Wikid77 (talk) 08:30, 19 September 2013 (UTC)
Thanks for the explanation. I've never noticed a problem with it in the past, and assumed it was VE-related (though I don't use VE). Parsecboy (talk) 20:33, 23 September 2013 (UTC)
Could you open an issue in bugzilla (if there isn't one already) and cc me? That sounds like a straightforward bug to fix, really. C. Scott Ananian (talk) 00:22, 24 September 2013 (UTC)
I added a comment to the bug report linked above (here), but I don't know how to cc you on the report. Parsecboy (talk) 13:33, 25 September 2013 (UTC)

Font changed (revisited)

Harking back to the thread of Sept 7th (Archive 116), has anything been made of this yet? I've looked at the Bugzilla thread, but unfortunately Google Translate doesn't handle that language yet. Peridon (talk) 13:17, 19 September 2013 (UTC)

I'm guessing you mean Google Translate can't translate technical English to plain English. I'll have a go for you: The most recent activity of interest is on 17 September, when Nikerabbit (Niklas Laxström) submitted a fix for languages that use Latin script (such as British and Canadian English). This is under review and has not yet been merged into the main code. – PartTimeGnome (talk | contribs) 22:23, 19 September 2013 (UTC)
Thanks. I just wanted to make sure this wasn't forgotten in some burst of other excitement. Peridon (talk) 19:08, 20 September 2013 (UTC)
Minor note, I followed up my previous query about the rationale for the existence of en-GB and en-CA, created a large synopsis, which resulted in a helpful reply, at mw:Talk:Localisation statistics#en-GB and en-CA - notes. This is just a pointer, for anyone who likes gritty details (or who can give additional details/assistance). –Quiddity (talk) 19:50, 20 September 2013 (UTC)
When setting up MediaWiki:Gadget-HotCat/de (see below), with my language set to "en - English", I noticed that the edit window was in a proportional-spacing font. After saving, I checked MediaWiki:Gadget-HotCat and found a monospace font; so I re-checked MediaWiki:Gadget-HotCat/de and found that it was still PS. I suspect that the internationalisation suffix (in this case /de) is taken into account. --Redrose64 (talk) 10:00, 21 September 2013 (UTC)
Solved Following a suggestion from MZMcBride (somewhere below the VE threads), I went to Preferences and selected 'Monospace' for edit windows. Problem solved. Something or someone may well have done one of those default changes that are so annoying. I know that I hadn't been into Preferences for at least several months and hadn't changed that one when last in there. Peridon (talk) 11:25, 25 September 2013 (UTC)

VisualEditor now opt-in only for all users on English Wikipedia

All,

This is a quick note to announce that we have reverted the English Wikipedia's configuration of VisualEditor to "opt-in" mode, from the "opt-out" mode that it has been since 1 July. This means that all users on this wiki will now only have access to VisualEditor if they have actively opted-in. We will continue to develop VisualEditor for all wikis, working with those in opt-out mode and users from those opt-in wikis who give their feedback.

Since it is apparent that the English Wikipedia was going to go forward with this plan, as custodians of the site it is our responsibility to find a less damaging and more consistent method for execution of the stated goals. We find it gravely disappointing that known-broken code was enabled for all users despite direct warnings to the participants of the damage it would cause.

Additionally, there is a desperate need to de-escalate this situation. Tempers around VisualEditor have been vitriolic for some time, and we seek a return to a calmer, more collegial working environment.

We continue to believe that this is a mistake: removing site functionality from new users who have expressed that VisualEditor makes their initial edits easier. We believe that the English Wikipedia will, in the long run, be damaged by this decision, but we cannot justify continuing to exhaust staff time (read: donors' funds) to this issue.

Yours,

Jdforrester (WMF), VisualEditor Product Manager 23:21, 23 September 2013 (UTC)

Too little, too late. Eric Corbett 23:29, 23 September 2013 (UTC)
Hm. You say you want to de-escalate and seek calmer tempers while still maintaining that this is not only a poor decision, but the site will be damaged. While I appreciate the action taken, this notice seems to contain bi-polar sentiments. Killiondude (talk) 23:28, 23 September 2013 (UTC)
@Killiondude: Sorry if my comment seems confusing; given the extensive comments from us about how the change would break the site, I felt that it was clear what I meant (e.g. an option to opt-in that doesn't work any more if you don't have any edits yet), but for users not involved in the minutiæ it was probably not obvious. My apologies. Jdforrester (WMF) (talk) 23:33, 23 September 2013 (UTC)
Please retract the accusation that I deployed "known broken code", Jdforrester. I took the feedback from Catrope and implemented it within the limits of what could be done from the client side, repairing all observable defects. I published it for review, and specifically invited Catrope to comment on the changes twice. The only possible remaining characteristic that could be described as "broken" was that it required a new account to make at least one edit with the wikitext editor before the editor could enable VE. No apparent fix for that was forthcoming, and one could argue that demonstrating the competence required to use a talk page was a feature, not a bug.—Kww(talk) 23:34, 23 September 2013 (UTC)
@Kww: "No apparent fix for that was forthcoming"? What does that mean? I'm confused. We were waiting for an opportunity to give further feedback, and further explanation as to why we thought this was a bad idea, when you posted it anyway. Also, "one could argue that demonstrating the competence required to use a talk page was a feature, not a bug" is the exact attitude that has been repeatedly proven turns away so many new prospective editors; you may wish to consider the impact you have on the community when such motives underlie your actions. Jdforrester (WMF) (talk) 23:44, 23 September 2013 (UTC)
Catrope was proposing to implement scripts that effectively implemented your failed proposal at the closure of the RFC. I repaired the code that didn't reliably disable it for the first edits by accounts or anons. I posted that repaired code in the morning and invited review. No one offered a suggested repair that would allow a client-side script to determine that it had already disabled the preference, nor was that a significant defect, given that the goal was to prevent inexperienced editors that cannot understand what went wrong when VE damages an article or repair the damage from using VE in the first place. That's where your goals are just plain wrong, James, and I don't know how many times it needs to be said: until VE actually works, it isn't suitable for inexperienced editors to use. If you have seriously read all of these comments and think of it as coming from someone that wants to ruin the experience for new editors, I despair of ever getting through to you. VE, as it stands, is more damaging to the newbie experience than anything in Wikitext. Broken tools are worse than difficult tools.—Kww(talk) 23:56, 23 September 2013 (UTC)
How much more feedback did you want that the community wanted VE turned off by default. Trying to engage the community now is several months too late. Dpmuk (talk) 23:59, 23 September 2013 (UTC)
(edit conflict × 2) @Jdforrester (WMF): You say "known-broken" code when one of your developers actually helped fix it. You were given two options - stubbornly keep it broken and let it go in as broken, or help fix it. You chose the stubborn one, and now are saying it's disappointing? You should be disappointed in yourself - thinking the community would not implement community consensus when it was able to do such. (post EC addition) You were asked for your help to disable it server side. You refused. You were asked, encouraged, to give input and fixes to the code. You refused. Thus, it was implemented as-is. I understand it may not have worked the best it could have, but it got the consensus implemented (one way or another), didn't it? ~Charmlet -talk- 23:36, 23 September 2013 (UTC)
As far as I understand, all the coding concerns brought by the WMF and its developers were addressed and corrected prior to implementation. I state this merely for the record. I suppose it is comforting to know that there is at least some point where the WMF will choose to respect the consensus of its community despite their disagreement with it, even though they had to essentially be dragged there kicking and screaming. It is also disappointing that their final word on the matter essentially re-enforces their original position, which tells us that although this particular incident is resolved for the time being, nothing has been learned, and we can probably expect more of the same in the future. equazcion | 23:38, 23 Sep 2013 (UTC)
@Charmlet and Equazcion: It is true that the first round of issues that we highlighted with the hack were fixed, yes - for which we are thankful. It would have been even worse had they not. However, code review doesn't work like this - it's not "one and done". You get reviews until everyone is happy, and do not deploy until it's been tested. Also, "You were asked for your help to disable it server side. You refused." is wrong - I said that I thought this was a very bad idea, gave reasons, and sought a discussion about alternatives. However, my request for partnership and working together was ignored in this case, which is indeed disappointing. And this is not remotely our "final word" on VisualEditor; we're going to be working on this for many years to come. :-) Jdforrester (WMF) (talk) 23:50, 23 September 2013 (UTC)
This is a contradictory statement. You are essentially saying you did refuse to disable it server-side. The fact that you offered reasons and wanted to discuss alternatives doesn't change that. Further, you appear to think that once the community determines its consensus, the community must then enter into a new consensus discussion with the WMF. I'm unclear on where this belief comes from. equazcion | 23:59, 23 Sep 2013 (UTC)
I find it gravely disappointing that we got to the point where we had to implement it ourselves because WMF would not despite an overwhelming consensus. I also find it gravely disappointing that this is coming across as "we've been blackmailed into doing but we're still right" rather than accepting what the community wants. I find it gravely disappointing that the WMF has wasted significant amounts of money on VE due to not doing the blatantly obvious thing of engaging the end users at an early stage. I find it gravely disappointing that the WMF is still blaming us for this whole mess while seemingly not even bothering to look at what it did wrong in this implementation. Unfortunately I also find it gravely disappointing that you were appointed to lead this project as it seems to me you're one of these people that are always convinced they're right and so won't listen to other people's views and that's not ideal in someone that's leading a project such as this. Dpmuk (talk) 23:55, 23 September 2013 (UTC)
@Jdforrester (WMF): You were asked to make the change serverside, yet you didn't. Nitpicking over my wordchoice doesn't help the damage control of the community's trust and opinion of the WMF that should be going on now. An actual apology should be forthcoming immediately, one that does not double back on the comments that got us to having to use the code in the first place. (by the way, I do expect the actual apology, and I expect it soon. Stop digging the hole deeper, and start trying to climb out with what's left of the WMF's dignity) ~Charmlet -talk- 23:58, 23 September 2013 (UTC)
@Charmlet: Fixing your comment: "You were asked to make the change serverside, yet you didn't yet." I am sorry that our seeking a discussion in a carefully-worded suggestion of ways forward came across as a refusal to engage; that was not my intent, and not my objective. Jdforrester (WMF) (talk) 00:05, 24 September 2013 (UTC)
You sought a discussion after the discussion had already concluded. That's too late. You should have come forward at the beginning and tried to compromise. Not after the consensus was there. I find it hard to believe you ever would have made the server-side change in absence of this incident. I'm sure the rest of the community would agree. I'm still waiting for an apology that isn't "you're all incompetent, but we'll do your stupid change anyway so we don't look bad"-esque, which this one is (don't even think of trying to weasel your way around that, it's what it amounts to and you all know it). ~Charmlet -talk- 00:09, 24 September 2013 (UTC)
@Charmlet: I agree that, in retrospect, I should have commented at the start of the RfC with my concerns and proposals. However, I didn't want to be seen to be "muscling in" on the community, or "telling people what to think" (which some off-line comments said my involvement would amount to, and that any discussion from me would be "wrecking" consensus). I'm sorry that I listened to those comments and didn't go with my gut instinct. I'm not sure who "you all" are meant to be (and I'd note that the community has banned users for accusing each other of 'weasel' words in the past, as you just did), so I'm going to let the final sentence slide. Jdforrester (WMF) (talk) 00:17, 24 September 2013 (UTC)
I, for one, am glad to hear Jdforrester say he regrets not commenting at the RFC. I hope it also means that he'd be amenable to a give-and-take in future RFCs (as opposed to merely commenting for the sake of declaring a static position). I'm not one to demand total on-the-knees apologies; I just look for indications of future changes. equazcion | 02:33, 24 Sep 2013 (UTC)
There you go mixing up the community with yourself again. Don't try to be a tough guy, it doesn't suit you. — Scott talk 00:21, 24 September 2013 (UTC)
Seriously? You're not going to respond as to why your "apology" sounds like "we're right, but we'll do this to try to make you feel a little bit better, you're still incompetent and the idea is still detrimental". That's not an apology. That's a "make me look right", which doesn't work when you're wrong (as is now). If you have an issue with my sentence, the appropriate channel is thataway. I've never heard of someone being banned for making a correct accusation, however, so I feel it's in your best interest to not try that. ~Charmlet -talk- 00:22, 24 September 2013 (UTC)
(edit conflict) LOL at "You get reviews until everyone is happy, and do not deploy until it's been tested" coming from the 'VisualEditor Product Manager'. – iridescent 23:58, 23 September 2013 (UTC)
Oh, the irony of that. I hadn't spotted that until you pointed it out. So everyone was happy with VE before you deployed it. Who did you ask? Just yourself? Dpmuk (talk) 00:02, 24 September 2013 (UTC)
Jdforrester:
  • "we have reverted" - by which you mean the community has reverted. This was not a WMF action and it is disgraceful for you to imply otherwise.
  • "gravely disappointing" - the community is gravely disappointed with the way the WMF has handled this situation, from start to finish.
  • "known-broken code" - an adequate description of VisualEditor with its hundreds of bugs spraying errors into the site.
  • "a more collegial working environment" - like one in which you listen to the community that you work for?
  • "We believe that the English Wikipedia will, in the long run, be damaged by this decision" - there's that "we" again; but this time it refers to you only.
  • "we cannot justify continuing to exhaust staff time (read: donors' funds) to this issue." - that's your fault, for a months-long saga of lack of adequate testing, bargain-basement change management, mangled rollout procedures, and inadequate and/or inappropriate communication with your major stakeholders. Don't try and recast this as having your time wasted; you have collectively wasted a vast amount of the community's time on this farrago. This is a colossal fuckup on all counts, and now you're going to reap what you've sown.
Your response here is absolutely characteristic of the condescending and dismissive attitude you have displayed towards the community throughout all of this. I for one will not shed a tear if you lose your job over this and are never seen around here again. — Scott talk 00:02, 24 September 2013 (UTC)
I'm to take this post where you insinuate that someone should be fired should be characteristic of both a collaborative attitude and the soul of consideration from the community toward the WMF? (I'm not saying you don't have a reason to be passionate, but Quid rides? De te fabula narrator. and all that) - tychay (tchay@wikimedia) (talk) 00:44, 24 September 2013 (UTC)
Typo: read narratur. S8w4 (talk) 06:05, 24 September 2013 (UTC)
A) Sorry pal, I don't speak Latin. Obviously communicating with plebeians is not your special area.
B) The community gave the WMF every chance it needed, time and again, to prove that it was capable of "collaborative" [sic]. It failed. — Scott talk 01:33, 24 September 2013 (UTC)
"Why are you laughing? You're telling the story" is a loose translation. Peridon (talk) 11:01, 24 September 2013 (UTC)
A) No, let 'me apologize. I assumed someone who spends their time posting image macros to Wikipediocracy would be adept in the use of the intarwebs. [LMGTFY]. For the "plebeians" (condescend much?) I was trying to politely point out that while you are understandably passionate, your post above was far more condescending and dismissive than James's.
B) Donor money is better spent engaging with community members who are willing to provide more constructive responses than "It's not ready" or "do it". I'll disengage and leave this segment of the thread for you to respond with something that is "absolutely characteristic of the condescending and dismissive attitude you have displayed toward" everyone here who is actually trying to have a constructive dialog. - tychay (tchay@wikimedia) (talk) 02:55, 24 September 2013 (UTC)
Mm. You know someone's upset when they start attempting to rake muck. For your information - and I know, despite you having "disengaged", that you're reading this - I easily spend two orders of magnitude more of my time editing this project - as I have been since 2002 - than posting to Wikipediocracy, so your attempt to malign my character is sad. I also don't bother to link to my profile there from here, so either you've been grubbing around searching for me, or, more likely, one of your buddies (I'll go out on a limb and guess Forester) put you on to it. I don't care either way. And no; I declined to play the "let them search for the meaning of my erudite statements" game the first time, so providing a hyperlink yourself won't convince me to now, either.
It's also telling that you choose to try and disenfranchise me with the implication that I, personally, am wasting donor money. You, whoever you are, do not get to make that call. Your job is to read and respond to community consensus. I'm sure you'll be familiar with that word; it's popular around here. The irony of your attempting to define "a constructive dialog", after the WMF ignored the collective voice of a great mass of people with a stake in the operation of this project, is glaring. It took an almost unprecedented display of the community flexing its muscle to force you to appear from whatever WMF zone you operate in and begin communicating with community members. (Your contributions history here does not indicate you to be such; the statement on your Meta user page that you "began editing Wikipedia in 2006" is only true in the sense that you made all of five edits from your Tychay account between then and your appointment at the WMF in 2012. You don't disclose the existence of any other accounts.) The manner in which you are interacting with bona fide members of the community on this page is how you and all of your team should have been operating from the start, and we can only hope that this is a lesson you will now internalize as an organization. — Scott talk 11:02, 24 September 2013 (UTC)
My reading of the original discussion follows: - tychay (tchay@wikimedia) (talk) 17:37, 24 September 2013 (UTC)
  • The broken piece was as alluded to by all parties (including James): a new user without an edit cannot opt-in. Asking @Jdforrester (WMF): to retract what all parties agreed to is true is absurd and people need to AGF and stop piling on. Perhaps he could clarify that the solution implemented by the ANI change was a limitation of using sitecss/js as a vector of implementing editor consensus.
  • I believe @Catrope: mentioned that there could be less-impactful implementations using the js to modify the style rule etc. However, it is not the job of the WMF engineers to fix every wiki admins user scripts and js. He was asked to audit the code for performance impact, which he did (that was the patch). Because the performance concern was addressed, the WMF did not block kww's implementation.
  • The "community consensus" we are assuming "the WMF must respect" is not the wiki community as a whole, nor is it even the community affected class of users: (anons were not asked to participate via site notice, there was only one anon vote on the RfC and only a couple votes by new users, anons and new users were not allowed to participate on ANI, VisualEditors were not able to participate on either discussion sections,). Instead, it was the consensus of editors who are interested in RfC and ANI policy, which represents less than 1% of the editing community. "Respecting" does not mean blindly following. It means trying to parse the useful feedback and changing. There have been a a number of changes made based on the RfC and other discussions, and a request to help further iterate on these changes, which is actually much further along than what happened with ACTrial, but I guess any sort of engagement is "disrespecting." I'm not saying that the disagreeing party is wrong (they're not!), it's that they don't have an obligation to anyone but their own community of enwiki admins, while WMF action has to balance those concerns with those of gnoming editors, anons, new and future editors, as well as the readers. Ideally I'd like to have seen some consensus with that. If not that, then compromise. For instance, why wasn't ACTrial implemented as sitejs or as a abusefilter (both of which were done during the course of the VE implementation). Was it because the WMF is more wrong here?
  • @Kww, Charmlet, and Equazcion: It'd be nice to just take the original post at face value, instead of being personally affronted. Consider the possibility that what is going on is very distracting to the VE teams productivity. Especially since many of the people brought into the discussion are engineers who are trying to improve the product and not tasked with making the executive/product decision on opt-in/opt-out/rollout. James unilaterally moving to opt-in allows people to refocus on making VisualEditor a better product and not engaging in political gamesmanship.
Though it adds nothing to the discussion, I'd like to see someone bring "wikitext editing should be hard and that's a feature not a bug" overton window-shifting to consensus among the editors or as a Board resolution. It's an interesting premise that cons istent with some editors' statements in some places (VE talk page and here), but inconsistent with statements by the same editors in other places (on the RFC or ANI). It's difficult for people who spend most of the time engineering to try to parse the consensus when peoples' positions shift depending on which group of they're speaking to. :-( - tychay (tchay@wikimedia) (talk) 00:25, 24 September 2013 (UTC)
Terry: You mean AN, not ANI. --MZMcBride (talk) 01:17, 24 September 2013 (UTC)
@MZMcBride: Yes, I did. Or rather, I should have. :*) Thanks for the correction - tychay (tchay@wikimedia) (talk) 01:24, 24 September 2013 (UTC)
  • It would be helpful, in terms of de-escalation and civility, if the involved WMF staff would clearly acknowledge the legitimacy of the opinion of the solid consensus of en-wiki editors that VE was also "known-broken code." Hullaballoo Wolfowitz (talk) 00:34, 24 September 2013 (UTC)
It was explained in response to Catrope that that behaviour wasn't a substantial problem, as the goal was prevent inexperienced editors from enabling and using VE. The only user class that this behaviour would unnecessarily inconvenience is when an experienced editor consciously makes a test account to use VE with: that account has to make one edit before the tester can enable VE. This was known behaviour, and, within the limits of the tools that were available, an acceptable limitation. Note that no one else objected to the behaviour, and I promptly fixed all of Catrope's other observations and tested the fixes. For someone that has released a piece of software so bug-ridden that it met with immediate demands for removal, someone that has fought tooth and nail to keep that buggy software installed, and recently released a new version with multiple substantial regressions where previously existing bugs came back to describe a piece of fully-tested code that did exactly what its designer intended as "known-broken" is hypocrisy at the very least. I view it as a conscious piece of deceit, and still believe that James should apologize to me.
To amplify Hullabaloo's comment: WMF is about to release seriously broken code on two dozen wikis. WIll he be gravely disappointed in himself?—Kww(talk) 00:41, 24 September 2013 (UTC)
@Tychay: I agree whole heartedly that the RfC only engaged some of the community. But insisting we engage the whole community is applying double standards as the WMF seems quite ready to implement stuff on what it thinks the community wants without consulting anyone other than itself which is, of course, an even smaller subset of the community. Unless I've missed it I've not seen any evidence yet where the WMF shows that anons etc support VE. Dpmuk (talk) 00:47, 24 September 2013 (UTC)
@Dpmuk: You make some great observations. I'll object that it isn't simply about what WMF (which is not a monolith) "think" because a lot of decision-making (including the decision to make VisualEditor in the first place) was informed by data, studies, etc. The thing you imply, which I agree, is that the editor community are experts: in editing, in many aspects of the community, etc. and there should be a better opportunity for those experts to inform the process (in this example, the process of VE rollout). That wasn't available at the time of the VE rollout and the bulk of the failure lies with either circumstance (the years spent working on VE, the current limitations in informing affected editors or exposure to VE when in alpha opt-in, the ensuing pressure to release, etc.) or on the part of the WMF, not with the editor community.
As for getting participation to the wider community beyond such polarizing processes such as RfC and AN, I am at a loss right now, but we (you, me, everyone on this thread) are all smart people and we're pretty empowered to affect change in this regard, so I suggest we try our best to do so.
Finally for anons support, I found one comment from an anon on the RfC and one crossposted comment on ANI that did not support VE. That it was the only comment that I replied to on AN is pretty indicative as to the weight I take this data. I believe about 13% of anons were using VE up until the opt-out default where now it will be 0%—I prefer to take the glass as half full in this regard because this was after the position of the tabs were switched the Beta was made prominent, and a warning was applied on edit, all of which are designed to discourage Anons from editing using VE without removing the option entirely. But I'm open to the glass-half-empty views of the same data. ;-) - tychay (tchay@wikimedia) (talk) 01:11, 24 September 2013 (UTC)
-Tychay, just so you understand my perspective, I think that having a Visual Editor is a great concept. I think it's a natural part of Wikipedia's evolution, and believe that a working visual editor will have an uptake rate of 90% or higher. That's just how the world works: people are used to Microsoft Word and similar tools for creating documents. The problem was that this particular visual editor was released when it was far too immature. It's not that it has subtle bugs or is missing a few bells and whistles, it's got document-shredding bugs, major features like table editing and cut-and-paste missing, and no plan for ever fully supporting templates in the ways that we actually use them. We keep telling WMF that, but we keep getting dismissed as if we aren't the "right part" of the community to say it. I look forward to a time in the next couple of years when Visual Editor is in good enough condition to undergo beta test.—Kww(talk) 01:35, 24 September 2013 (UTC)
@Kww: First let me theorize that James didn't mean to denigrate the effort you have put in the RfC, or the patch on VPT, or trying to get consensus on AN with respect to your patch on sitejs.
I believe you said much of this in the AN discussion and in another place (mailing list?) which I've read previously, as well as Eloquence conveyed this on your behalf. My position is that the VE will have to go through low uptake before it winds its way to 90% uptake (if ever), so that's a discussion point for another time. I think we (and I include myself) put unfair pressure on the VE team to roll out too fast, and it is this rollout and its disintermediation of the wiki editor community that is the undercurrent to everything being discussed. To your issues specifically: many of the document-shredding bugs have been fixed (many have not, but I think the rate is similar to that of wikitext editing as the reversion and block rates are in line with each other), table editing is very important but is easy to get wrong, cut-and-paste is a big one too, but is also so difficult that I found it's still broken on Google Docs. My feeling is that supporting templates the way you want to use them confounds visual editing with an IDE, which I think is important and worth some discussion, but is orthogonal. I don't think you're being dismissed —cut-and-paste and visual table-editing are both added to the near-term roadmap the last time I reviewed it, for instance — but I can see how it seems that way because communication, collaboration, and participation between the WMF and the community has been poor for quite a while. Believe it or not, it's poor within parts of the WMF, so your frustration is not unique. - tychay (tchay@wikimedia) (talk) 03:12, 24 September 2013 (UTC)
(edit conflict)@Tychay: My position on this is broadly similar to Kww's. I whole heartedly support the idea of VE, and think in principle it's a brilliant idea, but I can't support it's current implementation or how it's been rolled-out. I would also add that I can only support it if a text style editor is kept as an alternative. I will admit that I'm likely in a minority but I find it much easier dealing with text like the current editor than any visual editor and so can not support VE being the only editor.
You're not the first WMF staff member to indicate that the WMF are aware of the communications issues but it would be nice to see you doing something concrete about it, like coming up with a plan to engage editors in how to improve it. You can't just say you know there's a problem, you (the WMF) need to do something about it.
Sorry, but as far as I'm concerned it is essentially just about the WMF as we can see so little of the "data, studies etc." - I believe the latest user/reader survey results still haven't been released several months after it was conducted. That said I can definitely believe that people wanted something like VE what I struggle to believe is that they wanted it developed and deploy in the way it was or that the deployed version was so buggy. I expect the first two may mainly apply to experienced users but I would guess that everyone, including new users and anons, did not want such a buggy version released. I have yet to see any evedience from the WMF that anons etc want the current, incredibly buggy, version of VE.
I also think the WMF is concentrating too heavily on attracting new users. en.wiki and I suspect all sites will quickly fall apart with out experienced editors and admins - look at WP:CP where the backlog is huge to a lack of admins working this area. Now imagine this applies to vandalism, BLPs, everything. You'd quickly have a disaster on your hands. So why attracting new editors is a noble goal you should also be supporting experienced editors. For example, if in the extreme case (and I don't believe we are in this case) experienced editors are saying they're spending all their time clearing up after VE and have no time for anything else it wouldn't matter how much new editors like it it would need to be turned off. When was the last tool brought out that helped experienced editors with the roles they carry out? The last one I can think of is the edit filter and I don't know of anything on the horizon. This seems very skewed to me.
Finally thank you for being the first WMF staff member I know of to admit the problems have been more at your end than ours. Now if only we could get people more directly tied to this project (e.g. User:Jdforrester (WMF)) we may have more success with the compromises and the like of which you and other staff speak. Dpmuk (talk) 03:19, 24 September 2013 (UTC)


@Dpmuk: I believe many staff members feel that many of the issues regarding the VE rollout are either based on circumstance/environment, are on our end, or a combination thereof comprises the balance. I can't be definitive, but I've not seen uncivil words from the staff on the discussion pages, mailinglists, RfCs, AN, or VPT. But consider that many people, even at the WMF, are not in the position to influence these decisions—I, for instance, can only speak authoritatively to engineering decisions with respect to the VE, and not on the product, if even that! As one example, I don't know if rollout on some other wikis mentioned on the AN thread is, on the 24th, on the 30th, or some later date — I know that responsible discussions are happening though and that the final decision has been communicated to the release team, albeit a little schizophrenically and a bit last minute. Also, from our Monthly Metrics, in the annual plan, and in statements publicly for years, the VisualEditor beta release has been made many times. In the face of that, it'd be hard for staff members to feel that they were not adequately informed, and the their opinion might be seen as construed as speaking for the WMF, when in reality we're a lot like the community because many of us come from the community (JdForrrester included), and not some monolithic beast that does something without some differences of opinion here and there.
It is my understanding that the wikitext editor or some sort of source editing will be kept indefinitely. I don't think it's practical to expect otherwise. Perhaps this theory arose from the the hooplah around "Flow is VisualEditor, learn to be zen about it?" That's a good example of miscommunication. Extrapolating to a wikitext-less future on enwiki simply a confusion between the radical engineering design of the Parsoid part of the VisualEditor project/and the complete absence of any change in circumstance in the editing interface. Parsoid creates a bi-directional mapping between Wikitext and HTML which the current parser doesn't have. The current parser is uni-directional, from wikitext to HTML but not back; Parsoid allows seamless back-and-forth between HTML+RDFa and wikitext markup. Unlike wikipages, Flow stores parsoid HTML+RDF by default instead of wikitext. Flow, however, does not currently support VisualEditor and it is not in the "must-have" or "should-have" for the first release. The default experience is wikitext; the default storage is VisualEditor-compliant HTML+RDFa. What this might mean in real terms: most likely that the only way "out of the box" to edit Flow is with Wikitext, not VisualEditor. If VE is supported in Flow, it would probably be enabled behind a opt-in Beta Feature in early production releases. However, over time, it'd might become increasingly difficult (but never impossible by the definition of Parsoid) to take full advantage of Flow, without some of the affordances that VisualEditor-integration could implement. I'm not sure how that engineering nuance could be conveyed without turning into, "The WMF plans on killing wikitext editing in Flow."
Your example of WP:CP is an important one because it's a great example that more revolutionary approaches will fail on the wikis because they don't take into account the interrelated nature of the reader-editor-WMF ecosystem. It is also the reason why the VE research concentrated on reversions and blocks and was not definitive on productivity — the first priority was the former. As one example, mw:Echo development was pushed back almost 6 months from the Annual Plan commitment to work on Special:NewPagesFeed, which (I hope) is not a tool for new editor engagement. ;-) That's balancing competing concerns within just with one team — a team explicitly tasked with working on New Editor Engagement, without making any consideration about development done by Platform (Lua templating, single user login, …), Operations (SSL support, ToolLabs, …), Language (ULS, content translations, …), or Mobile (zero, …) all of which have the bulk of their projects focused on the reader or advanced editors. - tychay (tchay@wikimedia) (talk) 05:58, 24 September 2013 (UTC)
Addendum: I forgot to respond to "WMF needs a plan to fix the communication problem" While this is not VE, the discussions related to it has influence, this call-for-participation in Flow as an example. I hope you, and other, take it in good faith and realize the importance of your participation earlier in a project than after it has been released (or is about to be released) on enwiki. - tychay (tchay@wikimedia) (talk) 06:30, 24 September 2013 (UTC)
Tychay, the part that WMF dismisses (and you dismiss as well) is that new editors shouldn't be given access to an editing tool that is in that bad of shape. You quote reversion rates but neglect the effort that we put into following up on newbies and correcting their problems, rather than reverting them. We know that they don't mean to do those things to articles. No sensible admin is going to block a user because of a VE bug, so that measure is simply irrelevant. What's relevant is that VE cannot successfully edit a typical article on English Wikipedia, and, since the normal workflow relies on cut-and-paste, that "difficult" feature is actually a core feature. It's indispensable. We say that. Over and over and over and over and over and over, and we get told that we aren't sufficiently sympathetic to newbies or that we exaggerate things. No, we simply know what editing an article involves, and we know that VE can't accomplish it. It will, eventually, and if WMF would focus on clearing its bug list and trying again, it will get there faster. The constant insistence on rolling it out when you need to be rolling it back demonstrates that you are not listening. Or at least not believing.
Your theories about Mr. Forrester don't seem to be congruent with reality.—Kww(talk) 03:44, 24 September 2013 (UTC)
To your first point, I do not dismiss them. It's because I don't is the reason I'm careful to say we should be data-informed, not data-driven in our decision-making and why I'm careful to mention that the data is based on reversions and block rate. It's also why the original researcher posted data showing a decrease in productivity post-launch as well as a discussion of the data, instead of "letting numbers speak for themselves." I don't find the features you mention "indispensable," but perhaps this is because I have a different definition of that word based on my technical and engineering background. Personally, as long as wikitext editing exists as an alternative, I'm okay with it—it means the bulk of my editing is still done in source mode. From a technical standpoint, the consequence of omitting a "should have" feature like cut-and-paste in the minimum viable product is a drop in VisualEditor adoption and visual editing productivity. We've seen this. As for getting to the there where we do have cut-and-paste, that, I believe why JamesF has enabled opt-in on enwiki—to bring engineering focus back on working the product and not on these discussions.
To your second point. I believe the statement implies bad faith from a person who has been civil in his dialog and has admitted a number of mistakes where he ended up with compromise or consideration in action with respect to VE: in admitting failure in the way rollout was handled, in his initial stance on a VE opt-out user preference, in the initial position of the tabs, edit links, dialog boxes, and the beta badge, in his re-instatement of opt-in. I don't think anyone can point to a similar record in their actions, and I know I cannot in my own behavior. Given that agreement beyond simple empathy on that particular rant will out me as a hypocrite, you'll pardon me if I disengage and not respond further. :-) - tychay (tchay@wikimedia) (talk) 06:24, 24 September 2013 (UTC)
I too will disengage after a final comment, Tychay: if you can read what you just wrote and not understand why we feel like we aren't listened to, I grieve for you.—Kww(talk) 06:46, 24 September 2013 (UTC)

Wikipedia:Village pump (proposals)#Wikimedia Foundation employees are members of the community -- Just a thought. equazcion | 00:58, 24 Sep 2013 (UTC)


Dumping in text from VE feedback page. Someone else can de-dupe and re-thread. :-) --MZMcBride (talk) 01:21, 24 September 2013 (UTC)

I am EXTREMELY disappointed with the WMF's WP:IDHT attitude around VisualEditor! We the community made a clear statement and the WMF refused to hear it. Now they have the AUDACITY to try and spin it around so that we are to blame! Did the WMF suddenly decide to use the EA Games playbook? PantherLeapord|My talk page|My CSD log 01:51, 24 September 2013 (UTC)

"We find it gravely disappointing that known-broken code was enabled for all users despite direct warnings to the participants of the damage it would cause." Yeah, JDForrester, so were we. We were even more flabbergasted that it was muscled and forced in and it required an active revolt rather than a clear consensus to roll back. I am speechless at the irony in that statement. Seraphimblade Talk to me 01:59, 24 September 2013 (UTC)

I think it is brave of JDForrester to come here and admit disappointment in the way that a known-broken Visual Editor was rolled out. Bravo. Thank you, JDForrester, for coming here and making this statement, knowing that you would be dealing with the wrath of disappointed VE testers such as myself. I, for one, am disappointed — the stakes are too small for wrath, IMO — but look forward to a more mature, less destructive version of VE being rolled out once the significant bugs have been fixed and necessary features have been added. – Jonesey95 (talk) 04:20, 24 September 2013 (UTC)
Uh, JDForrester was referring to Kww's patch to disable VE as broken code, not to the broken and incomplete VE that he apparently approved the mass rollout of. Kww's "broken" code was necessary to fix JDForrester's horribly broken code as the WMF steadfastly refused to set it back to opt-in, but that was apparently elided. Hence my comment on very unfortunate irony. Seraphimblade Talk to me 04:31, 24 September 2013 (UTC)

Moving forward

I don't think finger-pointing (from either side!) will get us anywhere useful. I would have liked to have been in a position where, after the RFC, WMF and the community could have usefully explored compromise solutions together. Unfortunately the nature of the processes employed to-date makes it very difficult to view the relationship in terms other than power and authority, which is poisonous to rational debate. In coming weeks, I'd like to take forward ideas that enable more constructive, facilitated conversations to occur, such as a community-elected council that is empowered to negotiate iterative (but binding) changes to product rollouts on behalf of the community. Neither the "When an RFC says jump, jump" nor "Whatever WMF says, goes" model is conducive to a good long term development strategy.

As a reminder, we did (in response to and during the RFC) make significant changes to the VisualEditor integration to mitigate concerns. We were (and remain) concerned that a product of this complexity requires significant day-to-day usage from a broad and diverse group of users in order to be developed effectively. We'll continue to iterate from the current state towards a solution that gives VisualEditor the level of visibility that is required to continue to effectively develop the product while mitigating concerns that have been expressed.--Eloquence* 02:33, 24 September 2013 (UTC)

When the WMF seemingly insists on a "Whatever WMF says, goes" model is it any surprise that we have resorted to the equally extreme "When an RFC says jump, jump" model? Compromise should have been discussed before we reached this stage. All this take of compromise now is all well and good but it should have happened earlier. Rightly or wrongly you saying we should now try to compromise with WMF, despite completely unsuccessful attempts being made at this for several weeks, stinks of delaying tactics so that the WMF's preferred position (VE enabled) stays around longer. Dpmuk (talk) 02:59, 24 September 2013 (UTC)
Actually that's not really a fair characterization of events, Dpmuk. WMF made significant changes during the RFC process, precisely because it was clear that working towards a compromise was necessary. James offered further iteration on the existing implementation in his response after the RFC was closed, and opened a discussion about those proposals. You can say that none of these changes or suggestions go far enough, and they're certainly not a simple reflection of the RFC's outcome, but they were absolutely an effort to iterate towards a compromise. It just happens to be the case that our current decision-making processes aren't really well-suited for negotiation between WMF and the community on such matters. This pushes WMF to a desire towards more centralization of technical control, and the community to a desire to simply see outcomes of any RFC-type process implemented as is -- neither of which is the right answer. That's why I believe having the equivalent of an ArbCom to help negotiate in such situations could be valuable.--Eloquence* 03:16, 24 September 2013 (UTC)
@Eloquence: I suggest you read my user page before suggesting another arbcom like structure. While I support the basic idea comparing it to arbcom is sure to put my right of the idea! :-)
It may well not be a fair characterization of events but I think it's a feeling that I, and seemingly many other editors, have been left with and so how we've ended up with this feeling is something the WMF needs to do something about. I've long said (the first time was on Maggie's page several weeks, probably now months, ago) that I think the biggest problem with the whole VE debacle has been communication and here you suggesting it's the case again. It would be nice to see the WMF doing something concrete to work on the communication problem. I realise that answers are probably some way off but it would be nice if there was a plan and someone assigned to working on the problem.
When the community is after one big change, turning VE off by default, making small cosmetic changes such as relabelling stuff seems more like a way of you being able to say "look we are listening" rather than you actually taking our views on board. Meaningful compromise in my opinion would have been stuff like, "OK, we're turn it off until x,y,z is fixed". Whether intentional or nor your attempts at compromise did not really come across as compromise more as "what can we change that doesn't really affect our core ideas". That's not compromise. Again this may be a communication issue but that's how it come across. Dpmuk (talk) —Preceding undated comment added 03:32, 24 September 2013 (UTC)

Erik: I very much doubt that a new cabal and additional bureaucracy will make matters better here. ;-) While a simple solution such as introducing an ArbCom-like body may seem tempting, I think it dramatically misses the larger point: most software deployments are uncontroversial. I don't see hundreds of users lining up to criticize Echo or Parsoid or the redesigned user login form or better search functionality or Lua or VipsScaler or HTTPS support or .... It isn't about introducing new features or improving the user experience. I think many people want a decent visual editor. But someone, somewhere set an arbitrary timeline for deployment. And then subsequently someone, somewhere dug in. And the community started a request for comments. And some ground got lost. And then the request for comments ended and was partially ignored (or set aside, to be more diplomatic about it). And frustrated users decided to respond directly. Which led to even more ground being lost. Now VisualEditor is opt-in here.

And what's worse is that we now find ourselves in a position where the name "VisualEditor" is slowly becoming tainted. "VisualEditor" is transitioning from representing a large leap forward for the Wikimedia movement to representing poor community and expectations management, for lack of more nuanced phrasing. In my opinion, we need to figure out what went wrong here and learn whatever lessons need to be learned in order to try to ensure that something like this doesn't happen again. --MZMcBride (talk) 03:59, 24 September 2013 (UTC)

First, thank you for the fair assessment of the situation. You make good points. However, I think using the name ArbCom is a bad example of a good idea from Erik here. Something like a "community advisory council" is something community members have actually proposed to some success, though not without hiccups and objections. I'm not really sold on the idea myself, but the problem we'd be trying to solve is how difficult it is to communicate complex technical and user experience changes to tens of thousands of editors. Steven Walling (WMF) • talk 04:15, 24 September 2013 (UTC)
@MZMcBride: Thanks for the analysis. A small nitpick that should not diminish your larger point: Echo had numerous users lined up against it on one particular issue; there also was a giant petition on zhwiki concerning HTTPS; I won't get into ACTrial since that was before my time. :-) - tychay (tchay@wikimedia) (talk) 06:49, 24 September 2013 (UTC)
Eloquence mentions "a more constructive, facilitated conversations" and I think its the communication part which is the problem. In essence we have two communities the foundation/developers and en-wiki user base. Each community has its own means of communication, on-wiki for people on this wiki and off-wiki for developers. With two groups having largely separate discussions it is no small wonder that a lot of problems happen. What seems needed is a place where both communities have a joint conversation. I can't see such a venue at the moment. the feedback page and bugzilla are more to do with the nitty gritty and not higher level discussions and the foundation website and IRC are foreign territories for me. While there was some foundation presence on the feedback page this was people lower down the foundation ranks. What is really needed is someone at the top committed to have a conversation with users. When wikipedia started I believe Jimbo spent most of his time talking with users, this was what enabled the whole project to flourish. I think we have forgotten this vital point. Quite how this could happen I'm not sure of. Maybe a user council as Eloquence suggests, maybe the WMF should hire a VP for user communication? Is this a role for the trustees? We helped elect them yet I never hear from them once elected. Maybe theres a technical solution which allows a joint conversation to happen in multiple venues so a page on en-wikipedia is linked to a page on the foundations wiki. That way both communities can meet in a shared space.--User:Salix alba (talk): 12:49, 24 September 2013 (UTC)
@Salix alba: Just a minor nitpick but I think it has to be said: Larry Sanger, then Wikipedia's editor-in-chief, spent a lot more time than Jimbo talking to users and working on policies in the early days of Wikipedia. He used to sign with his initials, LMS; compare the links to the relevant redirect and the links to Jimmy's page on the Nostalgia Wikipedia for evidence. Graham87 03:21, 25 September 2013 (UTC)
Terry: Of course we're still subject to Ryan's Law ("All change, no matter how insignificant, unthreatening, or wholly beneficial, will generate controversy from somewhere."). But if we compare, for example, the new message indicator page with the VisualEditor RFC page, we can see that they're not on the same plane in terms of number of page watchers, number of edits, etc. We won't ever reach a state in which every change is welcomed, no matter how much pre-planning is done or how much forewarning is given. But we must examine anomalies such as the VisualEditor deployment and learn from them how we can do better in the future. When hundreds of users are coming together to say "whoa, stop this," we've already failed. With other large changes ahead (SUL finalisation, deployment of Flow, etc.), how we manage both the software and community expectations of it are increasingly important. --MZMcBride (talk) 14:19, 24 September 2013 (UTC)
@MZMcBride: You are 1000% correct. I just wanted to mention some history for others who may be reading your comment carelessly and feel that this is the only major editor community criticism of WMF decisions. While they didn't have the same quantity of criticism, these and others have the same quality of it. I hope mentioning this didn't diminish the larger point you made that how WMF and the enwiki editor community becomes responsive to this common pattern of interaction is the question we need to answer going forward. - tychay (tchay@wikimedia) (talk) 15:20, 24 September 2013 (UTC)

Analysis of the Forrester statement

The fundamental problem here is that WMF tends to use an advertising/press-release style of communication, where accomplishments are ballyhooed and failures are minimized and denied. In a press release, these things are forgivable and understandable. In discussions on-wiki, they come off as dishonest and evasive.

I'll take the infamous Forrester response to the RFC Wikipedia talk:VisualEditor/Default State RFC#Wikimedia_response and pick it apart with an eye to explaining to Eloquence why it failed so miserably in persuading anyone. Once we are past the "context section" we get to this:

  • "From an engineering perspective, while much work still needs to be done, the software is workable; it did not cause site-wide problems of the kind that would have made us disable it, and almost all of the page corruption issues are now fixed. From the point of view of the Foundation goals and the movement goals, it is fully within scope: we exist to allow for the creation and spread of knowledge, and VisualEditor enables that process."
  • Bear in mind that this is being read by an audience that has just told you that the software is too broken to use, and is generally aware of the ever increasing backlog of Bugzilla reports. The first really active statement simply tells your audience that it is wrong: while we may think the software is unworkable, that while we may be putting forth constant effort to repair site-wide problems, those things aren't actually true. And why aren't they true? Because they weren't "the kind that would have made us disable it". That last part ignores the fact that at this point the community had been begging you to disable it for ten weeks: you are justifying not listening to us now because you didn't listen to us in the past. Regardless of what you meant to say, the way this statement reads is "We are ignoring everything you said here, and the reason we know we are right to do so is because we ignored you in the past."
  • "One thing we have noticed, which we feel is beneficial, is that users are 6 times more likely to use edit summaries than with the markup editor – though earlier in VisualEditor's development it was more than 10 times more likely, and we're investigating what led to the shift."
  • It's been suggested that this statement is simply a misinterpretation of an odds ratio. That may be true. This statement, however, is not: for it to have ever been 10 times more likely for a VE-using editor to leave an edit summary than a normal editor implies that the VE rate was over 100% or the normal editor rate was under 10%. The former is impossible, and the latter isn't true. So, after the first statement tells us that you were justified to ignore us, you then make a false statement about the benefits provided by the software. At this point, I nearly hurled my coffee cup across the room. If this was an effort to make me feel listened to, what you've actually accomplished is to convince me that actually getting you to listen is a lost cause.
"We understand that the RfC is asking for VisualEditor to be a preference which has to explicitly turned on in order to become available. Our concern with this approach is that a preference available to registered users will skew VisualEditor towards use by experienced users only, and that overall usage will likely remain very low."
  • The thrust of this RFC was simple: the community felt that the software was too immature to be used by inexperienced users, and steps had to be taken to prevent the use of the software by inexperienced users. Your reply? That you couldn't do that, because it would reduce the use of the software by inexperienced users. This compounds the message of "we're ignoring you and won't address any of your concerns": you've looked at the primary result of the RFC and stated that you won't do that.
" However, we'd like to make the case that having the VisualEditor beta within reach for all users, without the need to flip a switch, will lead to a better product in a shorter amount of time, because it will get more real-world usage."
  • A recurrent concern throughout the RFC was that WMF was willing to compromise the quality of Wikipedia and to consume our time as editors in an effort to get better test exposure for VE because WMF is in a rush to get VE released. This part of the response does nothing to allay those concerns, and actually exacerbates it. We've said "slow down", and your reply is essentially "we can't do what you asked because it would mean slowing down."

All the exaggeration and spin in this statement is very understandable in the corporate PR world. If you were going to issue a press release about why you were ignoring the community I would expect it to read much like this, and it would be a rare corporation that didn't say similar things. In the context of a Wikipedia discussion these statements don't read the same way. In this context, they come off as dishonest. —Kww(talk) 16:12, 24 September 2013 (UTC)

  • +1. PR speak seeking to gloss over problems rather than addressing them is an unfortunate and pervasive WMF habit. Kww rightly picked it apart. I would go further and say that even in communications to the outside world, relying on corporate PR speak rather than openness and transparency about problems is counterproductive for a project like Wikipedia that relies on volunteers coming in to fix problems. A change in style would be very much appreciated. Andreas JN466 23:35, 24 September 2013 (UTC)
i wholeheartedly agree with this analysis. the VE team in general, and particularly Forrester, demonstrated an amazing deaf ear to the feedback from the community. at some point they even decided to remove the "Off" switch altogether (i.e., make it not even an "opt out" - just "no option"). only after enwiki created a silly gadget to turn it off, did they (grudgingly) graced us with an "Off" button in preferences, but they still felt compelled to "stick it to the man" with the text they insisted should accompany this off button ("temporarily disable" or somesuch), to make the point that this off-switch will not always be there, unlike (almost) any other new feature. imagine the developers of "Vector" skin or the "enhanced toolbar" behaving in a similar fashion. the same arrogance and deaf ear manifested on bugzilla: there are at least 3 (prolly closer to 6) different "bug reports/enhancement requests" that offer different solutions to reduce the amount of "nowiki" tags resulted from users creating links the old wikicode way (a little plug: i myself suggested many moons ago to solve it by treating the "[‎[" key combination as a hotkey for the "link" button in VE). i thought my idea was simple, attractive and natural, but even if you do not share this view, there were several alternative request meant to solve the same problem. the VE team valiantly ignored them all - apparently it was not a problem *for them*. i like VE, but the attitude of the VE team, and first and foremost, the attitude of Mr. Forrester, is abhorrent.
the line in his opening comments, "We find it gravely disappointing that known-broken code was enabled for all users despite direct warnings to the participants of the damage it would cause", is so funny and ironic on one hand, and so sad on the other, that there's really very little left to be said.
peace - קיפודנחש (aka kipod) (talk) 21:34, 25 September 2013 (UTC)

Communication with other wikis

It occurs to me that the mischaracterization of my patch as "known broken code" might serve to dissuade other wikis that find themselves in our position from taking the steps we did. What paths would be best for reaching out to such communities?—Kww(talk) 02:37, 24 September 2013 (UTC)

The user experience your hack created was definitely pretty weird. For example, the label would change from "Edit source" to "Edit" after creating an account, and the preference for VisualEditor would mysteriously not work at all til you're autoconfirmed. Those issues should be addressed before recommending this code to anyone else.--Eloquence* 02:49, 24 September 2013 (UTC)
It only required one edit before the account could enable VE, not four days and ten edits. I can work on the tab names: that's surmountable. I still have to wonder why some read "bron bewerken" and others read "brontext bewerken" in the current VE implementation.—Kww(talk) 03:02, 24 September 2013 (UTC)
Ah, I see you removed the autoconfirmed() check and replaced it with an edit count check. That's definitely better. I would still say, though, that causing a user preference to sometimes not work at all without any clear reason why is very broken behavior.--Eloquence* 03:09, 24 September 2013 (UTC)
Any Wikimedia wiki community wishing to opt out of (or opt in to) VisualEditor can make a request following the standard process outlined here: m:Requesting a wiki configuration change. There's no need for JavaScript or CSS tomfoolery. For the indefinite future, VisualEditor can be disabled server-side with appropriate local community consensus. I consider this principle settled. --MZMcBride (talk) 03:42, 24 September 2013 (UTC)
Hi. es:WP is development a poll about VE. We initially thought in vote, but that not allow to new users to participate, and supposedly they're the ultimate beneficiaries. Does this fill as "appropiate local community consensus"? Meta page says "Gaining on-wiki consensus and filing a shell bug does not guarantee that the request will be fulfilled" and that really worries me. Or maybe poll will be useless if en:WP decision affect others WP? Thanks. --Ganímedes (talk) 17:50, 24 September 2013 (UTC)
You should go through your local process to gain consensus. If the community decides it needs a change, it should try asking WMF. I believe that WMF has learned that it needs to respect community consensus on this matter. If there is difficulty, we have shown that it is possible to do it without them, but that hopefully will never be necessary again.—Kww(talk) 19:30, 24 September 2013 (UTC)
@Ganímedes: The comment you are worried about is expressing the fact that just because you want something does not mean it's possible. If flipping the switch you desire to be switched brings down Wikipedia due to performance problems caused by the switch, you won't get it, because having a working Wikipedia is more important than getting what you want. —TheDJ (talkcontribs) 12:26, 25 September 2013 (UTC)
Obviously, but we`re not talking about get what we want, or even a "demostration of power", as some user has claimed in es: when we started to talk about VE problems. We're talking about use community process and respect them. Of course, WMF can down the switch of es: and says "Well, as you don´t to what we want, there's no more es:WP" or any other WP. But certainly that will not stop users to edit somewhere else, and will no benefits anyone. Point is, when we started to discuss about VE some members of WMF and Tech told us: "we ain't see statistic"; we've got them stats: new editors use 50 - 50 VE nor WT; olders use VE only 25%. Who use it more are IP and patrolers says vandalism has grow... "Some users in VP are not hole community. When all community talks we'll see". Now there is the chance we make a poll, get a results and not be respected because... it's what we want, but not what WMF want? That is what worries me. --Ganímedes (talk) 13:45, 25 September 2013 (UTC)
I can not speak on that, I can only say that the line that you were concerned about is meant to indicate that user desires are not always technologically executable, might require serious amounts of programming work or other reasons that might prevent (speedy) execution of a desire. It indicates technical limitations not political limitations. —TheDJ (talkcontribs) 14:17, 25 September 2013 (UTC)

Help fix 3 months of VE nowiki errors

This is reminder to find prior pages with garbled "</nowiki>" text and correct them (see: search 100: "nowiki" "the"). Some twisted nowiki-tag text is so warped that I do not think a Bot could fix them (in some cases, 4 unrelated nowiki wikilinks have been inserted at each wikilink; see dif559). However, a common warped pattern is:

  • [[Thing|<nowiki/>]][[Thing (...)|Thing]]

In some cases, the fix can be just "[[Thing]]" but it might take a while to see it. The latest nowiki-tag error I have fixed from wp:VisualEditor was garbled into the page on 17 18 September 2013. However, hundreds of garbled nowiki-tag contortions have been saved for the whole 3 months, July through September, and I think at least 300 250 more pages need to be fixed. For a while, almost all nowiki problems were being repaired, by thousands of extra edits, but perhaps people burned out and left 300 or more unfixed pages. It has been 3 months of contorted text, in perhaps 40,000 pages (most re-edited to fix). -Wikid77 (talk) 04:22, 24 Sept., 17:32, 25 September 2013 (UTC)

If you're interested, I've modified WPCleaner to be able to detect nowiki tags in main namespace and propose adapted modification. I know some people use it regularly on frwiki to check the edit filter log for nowiki and clean the articles. By default, this detection is not active in WPCleaner, you have to do one of the two following modifications:
--NicoV (Talk on frwiki) 05:39, 24 September 2013 (UTC)

Unfortunate

This is just sad. It's a Pyrrhic victory. English Wikipedia has now disqualified itself to being even in the league of the mediocre and is now clearly placed in the terminal stage of software development. As a website it is the 2010 version of a Blackberry phone. It will be reliable but totally dead in the water and waiting to be overtaken by more innovative competitors. We are running out of time and we are all to blame, users, foundation and developers alike. —TheDJ (talkcontribs) 10:10, 24 September 2013 (UTC)

How in hell are users to blame? HiLo48 (talk) 10:31, 24 September 2013 (UTC)
Users are to blame, because the methodology chosen by the WMF to deploy this software in my opinion was partly inspired by the trouble of developing for this community in the past. 'we tried going slow, we tried going fast, we tried big changes and we tried small changes, now we have a mountain..... let's try a bulldozer because there is no other way to move a mountain' —TheDJ (talkcontribs) 12:38, 25 September 2013 (UTC)
Well, all doesn't include me. I looked at it, and went back to 'edit source' as being easier to use. Never edited with it at all. Or is that why I'm to share in the blame? (I've looked at Blackberry phones, and have an Experia because it's easier to use... I couldn't be doing with all those fiddly little buttons.) Peridon (talk) 11:15, 24 September 2013 (UTC)
When the WMF gets the software to work, which includes at least the most current version of Internet explorer, then we can and will reconsider the VE software. It isn't the communities fault VE was poorly developed and poorly implemented. If the WMF would have done a responsible rollout then we wouldn't have this problem either. The community did what we had to do to prevent damage to the project. That's something that the WMF should be doing but seems to have lost sight of that in the name of advances in technology. 71.126.152.253 (talk) 11:47, 24 September 2013 (UTC)
I would be interested to know what 'more innovative' competitors there are - and are we in a competition or providing a service? That sounds like a 'change = progress' statement. No. Progress involves change, but change does not necessarily mean progress. A vandal can change an article. An editor can revert the change. Which is progress? Neither. Progress is adding something good, or changing something to something better. VE didn't. It might, someday. But please get it right before trying to sell it to us. And do remember that not all changes are actually progress, and that adding chrome strips doesn't make a car more reliable. Peridon (talk) 12:22, 24 September 2013 (UTC)
Wikia, Wikihow, Baidu and even Wikidata spring to mind. But those are just giving the first hints, I 'fear' more those we don't know yet. Our response time to a major competitor I would currently base at about 4-5 years (in both technology and community processes). That's more then enough time for the world to pick a new favorite, while we all sit here reminiscing days gone by. Forking Wikipedia is difficult, but you only need to do it correctly once and we will all have to move and adapt or stop wether we want to or not. Once a competitor is successful we will be dead. This is not necessarily a bad thing btw. for the long term healthiness of the 'product' it might actually be desirable and healthy. —TheDJ (talkcontribs) 13:08, 25 September 2013 (UTC)
Off topic: The Wikia editor is actually better than VE in its current state and I couldn't imagine how that's even possible before I tried VE, given the Wikia editor is (from my point of view) a piece of crap: few and too weak features, unintuitive, etc. Everytime I edit on Wikia I switch to wiki text. 23PowerZ (talk) 14:55, 25 September 2013 (UTC)
  • Ask more computer scientists to join us: They have methods to fix wp:edit-conflicts for editing of adjacent lines (by improving diff3.c), or merge adjacent phrases on the same line. Imagine a classroom of 20 students asked to randomly wiki-update the same page, pick several spots top-to-bottom, and watch the edit-conflicts derail their efforts. Instead, I noted to stack multiple replies at the same line number into LIFO order ("last-in, first-out"), so a person could insert a new "===Subtopic===" after a line and the next to edit at that line would auto-stack the next sentence above the new Subtopic section. Long term, the wikitext editor could use "weave merge" of edits, where changes to paragraphs would be auto-merged even when another editor moved those paragraphs in a prior edit (by tracking relative line numbers as moved). Compare that to VisualEditor, where the entire edit session cratered on any (tiny) change saved in a recent revision, or a very large edit refused to save any changes, such as made by the most active student in the room expanding many paragraphs from new sources. However, VE is an excellent tool for a one-person wiki. Many organizations forget to provide tools which users need, tools to be used by all the users, together. -Wikid77 (talk) 19:24, 25 September 2013 (UTC)
Die Lösung

After the uprising of the 22nd of September
The VisualEditor Product Manager
Left a notice in the village pump
Stating that the community
Had forfeited the confidence of the foundation
And could win it back only
By redoubled efforts. Would it not be easier
In that case for the foundation
To dissolve the community
And elect another?

23PowerZ (talk) 13:22, 24 September 2013 (UTC)

Like it. Reminds me a bit of the failure of the Five Year Plan never being the fault of the Party... Peridon (talk) 16:37, 24 September 2013 (UTC)
Quite. Andreas JN466 23:37, 24 September 2013 (UTC)
Indeed. Begoontalk 00:45, 25 September 2013 (UTC)

Quick comment

I'm just going to say as a random user not involved here quickly that I am fine with the old system of "edit source" as it is simpler, easier and quicker to see the changes in some cases. Simply south...... cooking letters for just 7 years 14:48, 24 September 2013 (UTC)

Other comments on the removal of VisualEditor

— Preceding unsigned comment added by Helder.wiki (talkcontribs) 20:56, 24 September 2013 (UTC)

That thread has the most, well, succinct summary of the whole situation: "Unfortunately, the English Wikipedia's community held a request for comment that resulted in a request that the Wikimedia Foundation disable VE on that wiki. We have done so." Technically perhaps true, but "they made a request, and we have done so" is hardly a fair representation of what happened. "They made a request, we refused, so they did it without us. We then did it anyway, while making rather ridiculous complaints about wasted donor's money" would have been more correct. (Admittedly, that "donor's money" comment was refreshingly honest: since we are unpaid volunteers, our time and efforts are not important; but since some devs are paid employees, their time and effort are important; it's the old managament failure of "this project has cost so much money, we can't abandon it now", instead of looking at the actual results.) Par for the course at WMF, it seems... Fram (talk) 07:36, 25 September 2013 (UTC)
it's the old management failure of "this project has cost so much money, we can't abandon it now" - heh... been there, done that, got the t-shirt. I suspect that's not far from the mark - although not just monetary cost, it's hard to admit the effort hasn't had the desired result too. Except that's utterly the wrong way of looking at it. None of the effort will end up wasted, and all of the mistakes can, and should, be learning moments. As I've aged I've become far less concerned about making mistakes (though, like anyone, I still prefer to avoid them - they can be embarassing...), and more concerned about how I recover from that inevitability. Not perfected it yet, but I've not finished living or learning yet. Begoontalk 12:57, 25 September 2013 (UTC)

Is there a way? Shouldn't this be a choice by default? Or an opt-in to English, with the option to see the other representations of the languages? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 09:17, 24 September 2013 (UTC)

There is a userscript that does that: User:Equazcion/SidebarTranslate. —TheDJ (talkcontribs) 10:14, 24 September 2013 (UTC)
That's fantastic. Thanks. Does anyone know if this is already a feature request in Bugzilla (to change the default), or should I request something? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 10:29, 24 September 2013 (UTC)
The default is a conscious choice (by request of the community if I remember correctly) to help guide users to their 'native' language, not for experienced users to guide them to interesting non native languages that they apparently can't read. Anything is possible, but this is one of those issues, where I would say that it's unlikely to be implemented before someone has measured the input from the various wiki communities. —TheDJ (talkcontribs) 11:43, 24 September 2013 (UTC)
I seem to recall seeing that decision as well, but I can't exactly recall when. Equazcion's script is great; perhaps we should consider adding that to the list of widgets in Preferences. — Scott talk 13:03, 24 September 2013 (UTC)
I wish I could take credit but the original script actually wasn't my doing. I just made a copy to fix up after some MediaWiki changes left it a little quirky, added a feature or two and made the documentation page. You can see the credit section at User:Equazcion/SidebarTranslate for the various authors. I do agree this should be at least a gadget. equazcion | 13:08, 24 Sep 2013 (UTC)
That's a great script, particularly the googletranslate links (can you fix the https problem with those?). I support adding it as a gadget, and/or integrating it with ULS. –Quiddity (talk) 19:54, 24 September 2013 (UTC)
Quiddity, should be fixed now. equazcion | 20:46, 24 Sep 2013 (UTC)
Equazcion, you might consider checking out $.uls.data.languages in the console. It might be useful. ;) (Edit: I meant wgULSLanguages or mw.config.get('wgULSLanguages'). It's missing a few, but it has the most common.) πr2 (tc) 00:19, 26 September 2013 (UTC)
I think Bugzilla:5231 and Gerrit:35871 (Mouseover explanations for interlanguage links in native language) is the closest existing bug/request. The Gerrit patch seems to end with Jenkins requesting a rebase. I poked Siebrand a few days ago, but he didn't respond (probably very busy on other things); possibly another dev could help push it along? But bearing the above discussion in mind... –Quiddity (talk) 19:54, 24 September 2013 (UTC)

Blacklist not functioning correctly

WP:BEANS - The Bushranger One ping only 03:07, 26 September 2013 (UTC)
The following discussion has been closed. Please do not modify it.

{{tracked|54598}}

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


It appears that the blacklist has serious security flaw. Well to qoute the discussion from my talk page:

Add it as a plain link to your sandbox. Cyberpower is getting curious, and then try to add as a ref as you just.—cyberpower ChatLimited Access 12:09, 25 September 2013 (UTC)

Heh... Blacklist blocked as plain link, but added with no problem as ref. Begoontalk 12:14, 25 September 2013 (UTC)
Which is alarming because the blacklist filter isn't doing it's job right. The blacklist can be bypassed by using it in a ref.—cyberpower ChatLimited Access 12:16, 25 September 2013 (UTC)

Apparently the blacklist can be bypassed if blacklisted links are added as a ref.—cyberpower ChatLimited Access 12:19, 25 September 2013 (UTC)

  • Blacklist URL links can be in refs but not reflist'ed: As long as a forbidden URL does not get wikilinked onto the formatted page, they can be hidden inside reftags, <ref>...here...</ref>; however, adding a {Reflist} or "<references/>" will prevent the page from being saved because the links to the forbidden webpages would be active on the formatted page. -Wikid77 (talk) 14:39, 25 September 2013 (UTC)
    Ok. Sorry my bad. I have confirmed that.—cyberpower ChatOnline 15:04, 25 September 2013 (UTC)
What the hell? Did you miss the notice at the top of the page that specifically says "Bugs with security implications should be reported to security[at]wikimedia.org"??? Legoktm (talk) 17:25, 25 September 2013 (UTC)
  • I agree with Legoktm here, this shouldn't have been brought here. Anyways, how picky is it? Can you hide the URLs in one edit and get them to show up by adding the reflist in another? Perhaps with ... Stopping here for WP:BEANS... I'll do some of my own testing and add it to Bugzilla... Technical 13 (talk) 18:15, 25 September 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Yesterday's slowness

Did anybody figure out what caused Is preview slower than usual? It had been totally gone when I logged in a few hours ago. Within the last hour, I've noticed the phenomenon creeping back in while I edit. — Maile (talk) 20:01, 25 September 2013 (UTC)

nowrap vs please-wrap-here option?

We know the "nowrap" option. Is there a way to say to the browser: "within this text string, if you have to break, then break here first?" It has a nesting (level of priority) edge. -DePiep (talk) 17:03, 15 September 2013 (UTC)

<wbr> (see Wikipedia:Line break handling#wbr). Edokter (talk) — 17:36, 15 September 2013 (UTC)
<wbr> is a wikicode thing then (not html)? OK with me if it works...
...but the linked example fails over here (Ff atop WinXP). -DePiep (talk) 18:00, 15 September 2013 (UTC)
(edit conflict) <wbr> is an optional break position, and it is HTML - it was introduced with HTML5. It has the same "priority" as a normal space; the browser will break the line at whichever of these allows the most text to be displayed across the available width, regardless of whether it's at a space or a <wbr>. I am not aware of any technique that will give one position priority over another. --Redrose64 (talk) 18:03, 15 September 2013 (UTC)
Linked example works for me (FF 23.0.1 on Win7 SP1) DKqwerty 18:13, 15 September 2013 (UTC)
re Redrose64: HTML it is then. But as described, <wbr> is the same as an &#x20; space. So I cannot control (set preferences for) this kind of linebreaking. Seems like we are entering "stateless" territory, for which I have no passport. -DePiep (talk) 18:56, 15 September 2013 (UTC)
It's not the same as a space. If you use it within a word, no extra space appears; if you use it between words, you also need a space otherwise the two words are butted together (and when there is an explicit space between words, a <wbr> is pointless). Consider super<wbr>cali<wbr>fragilistic<wbr>expiali<wbr>docious → supercalifragilisticexpialidocious and vary the width of the browser window, to show the wrapping. --Redrose64 (talk) 19:59, 15 September 2013 (UTC)
I know these effects. It is space & whitespace behaviour. Also, is has Unicode props (does it diff from zero whitespace really?). My question was, can I steer "nowrap" from within its brackets. I am from structured programming, not streamed (PHP) programming. -DePiep (talk) 21:05, 15 September 2013 (UTC)
If you are asking if <wbr> works inside {{nowrap}}, then no. You can join strings of words with {{nowrap}} with a simple space where you want the opportunity for a break. Otherwise, please provide an example of what you are trying to do. --  Gadget850 talk 22:01, 15 September 2013 (UTC)
This answers my question. -DePiep (talk) 22:55, 15 September 2013 (UTC)
(edit conflict) The {{nowrap}} template is wraps the text string in <span class="nowrap">...</span>, and the nowrap class has been set up to apply the CSS styling white-space:nowrap. This causes any <wbr> tags that may be present in the string to be ignored. It's easily tested:
Let's not disrupt the flow of the rest of the page...

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

where I've added a <wbr> after the fifth letter of any word of ten or more letters. There is no word wrapping for me (Firefox 23). --Redrose64 (talk) 22:09, 15 September 2013 (UTC)
There is, however, word-wrapping on both Chrome and Opera 12. Some of these browsers must be wrong, but I don't think I am in position to tell which ones :) Matma Rex talk 23:14, 15 September 2013 (UTC)
Hmmm, it also wraps in IE7 and Safari 5.1.7 --Redrose64 (talk) 23:36, 15 September 2013 (UTC)
  • Try nowrap of word-joined phrases: I have thought about similar problems, for years, to prioritize one break spot over another, and the best solution I have found is to have several nowrap groups, as word-joined text after the likely break spots. For example, use the joiner template, {{j}} for phrases:
  • "wrap among these words but {{j|not in here}} or these {{j|2 words}}, {{j|nor here}} {{j|nor this}} spot"
With multiple word-joined phrases, set by Template:j, then when users display a line with browser TextSize zoom set larger, the related words will "magically" clump together to avoid awkward splits between closely-related words, and help sight-impaired users view the connected phrases. By word-joining the "{{First 3 words}}" of a paragraph then that can ensure enough width to fit longer words afterward and prevent too-short widow/orphan lines in the related text. I think the use of word-joined groups will solve most cases of awkward wrapping, as long as the groups are kept relatively short. We specifically defined template {j}, 3 years ago, as a short name to typeset these word-joined cases. If we controlled the improvements for MediaWiki, I would define "\_" as "&nbsp" in wikitext markup, as in "join\_these\_words" along with setting parameter 1 as "#[1]" or similar to avoid wiggly syntax "{{{1}}}". -Wikid77 21:45, 15 September 2013 (UTC)
The "separate nowrap strings" construction. Even then, I can not control them. What with breaks between nowrap-1 and nowrap-2 string? -DePiep (talk) 23:00, 15 September 2013 (UTC)
It is the solution, but in reverse, because not wrapping between 2 words is the same as allowing to wrap either before-or-after them. The words either wrap, or they don't, and there is no 3rd option to consider. Hence, by deciding where to no-wrap the text, then the problem of clever wrapping is solved, but in reverse. Try it in several cases, and it will make more sense. Now, a related problem is the gapping caused by wrapping long words, and the solution is to either reword a long word as 2-3 words or use a word which can be hyphenated to wrap, such as "worldwide" respelled as "world-wide" as a valid option. Those tactics will provide logical wrapping. -Wikid77 07:48, 19 September 2013 (UTC)
There is also {{wrap}}, which inserts a breaking space inside a {{nowrap}} block. Edokter (talk) — 18:44, 16 September 2013 (UTC)

You may be interested in the work-break property. --MZMcBride (talk) 04:47, 22 September 2013 (UTC)

Incidentally <wbr> support was added relatively recently to wikipedia (https://bugzilla.wikimedia.org/show_bug.cgi?id=52468) so if you're running on a private wiki you might want to double-check that your mediawiki install is up-to-date. C. Scott Ananian (talk) 00:19, 24 September 2013 (UTC)

"zero-width" alternatives

I find zwsp (zero-width space) marvelous for such conundrums..., er, conundra..., um, conundrumata,... whatever. For years I was driven infuckingsane—psychoneurotic!—because such constructions as infuckingsane{{mdash}}psychoneurotic!{{mdash}}because won't break anywhere. Coding infuckingsane{{mdash}}{{zwsp}}psychoneurotic!{{mdash}}{{zwsp}}because gives infuckingsane—​psychoneurotic!—​because (i.e. visually identical output) which breaks beautifully when needed. My impression is that zswp has higher priority for breaking than just a space, but not sure.

More recently I've discovered a way to handle an admittedly more unusual situation. Suppose you've got a link followed by a ref, such as invaded by [[William the Conqueror]]<ref>Smith, p.5</ref> in the winter, giving

invaded by William the Conqueror[1] in the winter

As coded this will allow a break between Conqueror and the superscript cite callout, and suppose we want to prevent that. We could use invaded by {{nowrap|[[William the Conqueror]]<ref>Smith, p.5</ref>}} in the winter. but that makes the whole phrase unbreakable, which is undesirable. Turns out there's a zwnbsp which disallows a break. invaded by [[William the Conqueror]]{{zwnbsp}}<ref>Smith, p.5</ref> in the winter gives

invaded by William the Conqueror[2] in the winter

I created the zwnbsp template and yes, I know it inserts a character documented as deprecated in favor of another character which is supposed to have the same function. But I found that the other character doesn't work, at least on IE9, and zwnbsp does work, so there you have it. Maybe some of you wizards can sort that out.

EEng (talk) 01:23, 26 September 2013 (UTC)

  1. ^ Smith, p.5
  2. ^ Smith, p.5
One problem with using invisible characters for such purposes is that if you copypaste from the screen, the invisible character may get copied as well, possibly with undesirable consequences, such as broken wikilinks. This template is in Category:Stub message boxes needing attention because its |category1= ends with a U+200E Left-to-right mark, almost certainly copypasted from somewhere else. This template had exactly the same problem, until I fixed it. You may have noticed that there are bots that "remove unicode control characters" - U+FEFF and U+200E are among the things that these bots remove, because they cause so much trouble. By contrast, <wbr> inserts no invisible text at all if the word does not need to be broken, and copypaste works as expected, even if the copied text spans a line break. --Redrose64 (talk) 09:09, 26 September 2013 (UTC)
Surely there's some way to set up the edit window to forbid / make visible / substitute invisible characters, or do the same on the server side as te4xt comes in. EEng (talk) 13:03, 26 September 2013 (UTC)

Problems with stale pages

Hi, I'm seeing some stale pages (many hours old) that do not show my latest changes even after doing the "purge" thing, and, what's more, even the "View history" pages are out of date and do not list latest edits. Affected pages are http://en.wikipedia.org/wiki/Talk:Main_Page and http://en.wikipedia.org/wiki/QVC_(UK). Are there any known problems? 86.160.211.148 (talk) 02:17, 24 September 2013 (UTC)

Update... this page is now also affected. When I first saved the message above, the new thread was visible. Now the final thread that I see on this page is "Space, the Wikipedia frontier", with last message posted at 19:54, 22 September 2013, which is way, way out of date. The most recent edit listed on the "View history" page is 06:40, 23 September 2013, which is also many hours old‎. However, when I go in to edit the page I do seem to see the most recent version. At least I hope so. Nevertheless, something is obviously messed up. 86.160.211.148 (talk) 02:51, 24 September 2013 (UTC)

Bit hard when it doesn't do it for us (OK, me anyway...). How are you clearing the cache? I find Ctrl-F5 usually stops the irritating quirk of the browser of sometimes giving a cached version when you ask for a reload. (At least till the next time...) (Why the hell did the designers build that in? I mean, if you ask for reload you want an update not the page you already had.) Peridon (talk) 16:45, 24 September 2013 (UTC)
I have physically deleted all local cached files and I still see the old versions. Wikipedia (or something between me and Wikipedia) is serving pages a day or more old, even on the "View history" pages. Behaviour is variable and unpredictable. Sometimes I may see an up-to-date page, then it goes back to the stale one. This happens repeatedly over a variety of different pages. It is nothing to do with local caching. Purging Wikipedia cache also makes no difference. 86.160.209.82 (talk) 20:52, 24 September 2013 (UTC)
Possibly there is a proxy or cache between you and Wikipedia (likely not Wikipedia's own caches, since then we would have seen more complaints by now), that is giving you these old pages. There is little that we can do about that, it's often an ISP that is to blame. If you log in, caches usually get bypassed, so that might work as a workaround. —TheDJ (talkcontribs) 12:13, 25 September 2013 (UTC)
Thanks, I have no way of telling for sure, but my feeling is that this is a Wikipedia error and nothing to do with any intermediate caching. I regularly use other sites (e.g. forums) with rapidly updating content and I have never once noticed such a thing on any other site. It's only ever with Wikipedia that this happens. 86.160.220.63 (talk) 17:27, 25 September 2013 (UTC)
... by the way, why would logging into Wikipedia cause third-party caches to be bypassed? 86.160.220.63 (talk) 17:28, 25 September 2013 (UTC)
Caching whatever forums you might be visiting might not be worth it for your ISP (unless they're similarly popular as Wikipedia). Logging in should bypass the caches because the HTML generated for every anonymous user is the same, but the HTML generated for every logged in user is different (if only because your username in included in it, but there are other things), so caching it, again, is not worth it. (There are also the security implications of caching content that is only accessible with a password.) Matma Rex talk 17:54, 25 September 2013 (UTC)
Thank you for your advice. Personally, I am very sceptical that this is anything other than a Wikipedia glitch. I also look at popular news sites, for example, and I have never ever seen any page noticeably stale (which I would notice, certainly when a day or more old). 86.160.220.63 (talk) 20:40, 25 September 2013 (UTC)
There is a difference between a glitch that is Wikipedia specific vs. something that is a glitch in Wikipedia. —TheDJ (talkcontribs) 09:05, 26 September 2013 (UTC)
Possible, but unlikely. Most likely this is a problem with Wikipedia. There have been problems with Wikipedia sometimes serving stale pages that have been ongoing for many years and have never been properly resolved. 86.171.43.177 (talk) 11:29, 26 September 2013 (UTC)
The problems are still the same, by the way. For example, the only way I can participate in this thread is to click "Edit" and search the source to see if there have been any further comments. Viewing the page gives me a random earlier version hours or days out of date. 86.171.43.177 (talk) 11:33, 26 September 2013 (UTC)

Can I switch to a font which distinguishes between an upper case I ("eye") and lower case l ("ell")?

I saw the article Richard Ieyoub and thought that it was displaying his last name starting with a lower case L. Only after copying it and pasting it into Google to see if there was some special cultural justification for his having a lower case last name did I see a different font displaying the letter in question as an upper case i, with serifs or whatever. The default display font leads to oddities such as Ill being the same as III and lll. Ill was the day they chose this font. Only by context is it clear what the letters are in the beginning of Illinois or Illegal. For a name or an unfamiliar word, the reader is left to guess what letter the vertical line represents. This could be a problem in typing a username as well, requiring a cut and paste to input it accurately, since a username might have any combination of upper and lower case letters, such as User:I versus User:l , both of which accounts actually exist. So is there a way for me to get Wikipedia to display in a more legible font, which distinguishes between upper case I ("eye") and lower case l ("ell")? Edison (talk) 15:04, 24 September 2013 (UTC)

Wikipedia doesn't force a font but uses a default in your browser. See Wikipedia:Typography. If you dislike Wikipedia's font then logically you should also dislike it for other websites that don't force a font (many do force it). You can probably change your browser default. If you don't know how then say which browser you have. PrimeHunter (talk) 15:48, 24 September 2013 (UTC)
Butting in here. I've seen comments like this about browser default before. My browser default is 16pt Times New Roman, and I've never seen it do anything at all yet - anywhere. (Firefox 20.0.1 on XP Pro with Monobook on WP). I've done a lot of type setting and I'd spot TNR 16pt if it appeared. I like sans serif for headings, but hate it for body text. I've never bothered to change the 16pt default because, very simply, it doesn't do anything anyway. I'd like to get rid of this bastard typeface on the edit windows that seems (they say) to be a bug. Peridon (talk) 16:21, 24 September 2013 (UTC)
Peridon: Wikipedia (or rather MediaWiki) doesn't specify a specific font, but it does specify the generic font family "sans-serif". Many Web browsers have different font settings, usually one for serif, one for sans-serif, and one for monospace. Times New Roman is a serif font, so you won't see it in use here by default. We have various articles about all of these type families if you're interested.
Regardless of the above, the edit window (and other user interface inputs) are treated differently by most Web browsers (or more technically by most operating systems). You can specify an edit window font by visiting Special:Preferences#mw-prefsection-editing (the default edit window preference is to use your Web browser's default). In addition to being able to specify an edit window font, registered users can also override styling of nearly any part of the site using a per-user JavaScript or CSS page. For example, you can require that the entire site use Comic Sans. If you have any questions about how to do this, this technical village pump is the appropriate forum in which to ask. Hope this helps. --MZMcBride (talk) 17:47, 24 September 2013 (UTC)
Great, thanks. Monospaced again, and I can count the colons again. And L l and I are separate again. Peridon (talk) 18:04, 24 September 2013 (UTC)
Click the gear next to "languages" in the sidebar. You should have two selections - try the OpenDyslexic font. I find it helps when I'm tired (always...), it adds weight to the bottom of letters, which distinguishes them more. I'm not sure that browser defaults transfer automatically to Wikipedia pages, as mine don't. ~Charmlet -talk- 16:25, 24 September 2013 (UTC)
This is probably not the way one is supposed to do this, but if messing around with your browser fonts isn't for you, you can force it for Wikipedia only: Just put:
body{font-family:serif;}
into your common.css, and that should do it. Writ Keeper  16:27, 24 September 2013 (UTC)
I've looked at that for the first time. Is there a bugzilla about it being improperly localised? It gives me the choice to "Lettertype selecteren voor English Lettertype voor inhoud." If it wants me to select a font type for English, it should localize the word to "Engels". If it is going to use it for all western languages, it shouldn't specify "English".—Kww(talk) 16:39, 24 September 2013 (UTC)
The "Zing!" sound was the result of a lot of the helpful comments going right over my head. Writ Keeper's link led to an error message which says "The requested URL "https://en.wikipedia.org/wiki/User:Edison/common.css" cannot be found or is not available. Please check the spelling or try again later." I typically use Foxfire browser. But when I initially tried to Google the name I mentioned, via cut and paste, it displayed serifs which showed it to be an I rather than an l (sorry if they display the same in this bastardized display; the first is an upper case "eye" and the second is a lower case "ell.") The problem seems to be more specific to Wikipedia than generalized to the browser. Do they display different to other users? I have never taken any intentional steps to make my computer display letters ambiguously like they currently do. I shouldn't have to go through exotic gyrations to make I and l look different. Sans serif is ambiguous and fundamentally illegible, and it should not be inflicted on encyclopedia users.(edited after one response, for clarity) Edison (talk) 05:19, 25 September 2013 (UTC)
*shrug* Them's the breaks. If you want to try my CSS hack, I can step you through it or just do it for you, if you like. It's pretty much seamless once it's done. Writ Keeper  05:29, 25 September 2013 (UTC)
Hmm, try the direct link, then: User:Edison/common.css. Creating that page with the body{font-family:serif;} should do it. Writ Keeper  05:42, 25 September 2013 (UTC)
I date back to punchcards, papertape, and Fortran IV. I don't know CSS. Edison (talk) 05:45, 25 September 2013 (UTC)
Punchcards, paper tape, and Algol 60 for me, and I still managed to learn CSS. It's not that tough.—Kww(talk) 06:30, 25 September 2013 (UTC)
Fortran IV, with Watfour and Watfive ~ one of my favourite titles of all time. Is there any particular resource you would recommend, Kww, to make an attempt at starting CSS? Kahtar 14:43, 25 September 2013 (UTC)
Watfive? You're a young'un, aren't you? Anyway, http://www.w3schools.com/css/ is as good a place to start as any.—Kww(talk) 15:59, 25 September 2013 (UTC)
Pasted the suggested text into CSS and it made the desired change so that I and l look different in displayed text in articles, although they are still sans serif and identical in an edit window, which is not really a problem. Previewing before saving takes care of any ambiguity. Thanks to all. Edison (talk) 19:20, 26 September 2013 (UTC)

Currently, Wikipedia:Proposed mergers is sparsely populated and does not reflect the vast majority of merge proposals. There are thousands of pages with proposed merge templates, and many of these are little discussed and not on the radar of the editors who would be best suited to close them. I propose that we adopt the practice now used very successfully at Wikipedia:Requested moves, where a standardized talk page template introduces the merge proposal, and all of these templates are transcluded by date into a single discussion page (although, given that there is a far bigger backlog of merge requests, we might start by having pages divided by month or year, depending on the numbers). bd2412 T 20:06, 24 September 2013 (UTC)

Did you mean to post this at WP:VPR, since it's not a technical question?
At any rate, your proposal solves the wrong problem. Those backlogged merges do not need "more discussion" or "more eyes" or "someone to officially close them". They need people to do the very boring work of actually merging the pages. (PM only lists the merge discussions that might turn into fistfights, not the routine ones. It's similar to the distinction between PROD and AFD.)
AFD has the same problem with pages that close as a merge, by the way. Last time I checked, there were 150 pages sitting in the "Okay, I closed it as 'merge': now won't somebody actually merge it?!" category. WhatamIdoing (talk) 17:42, 25 September 2013 (UTC)
It's a technical question to the extent that the technical setup needs to be created to allow this. I also happen to think that many merge requests could indeed use more eyes or more opinions. I see many that have been proposed by templates on the articles, but never discussed at all. bd2412 T 17:50, 25 September 2013 (UTC)
You are far from the first to raise this issue. See Wikipedia:WikiProject Merge. You're encouraged to become the 26th volunteer to sign up for this project. You could start by putting your eyeballs on Colorado counties and List of counties in Colorado. The WikiProject has tried to kill this proposal several times, but there are editors who refuse to let it die, and seem incapable of doing the merge themselves. Can we hire the Wikimedia Foundation to do the merge for us? Wbm1058 (talk) 18:55, 25 September 2013 (UTC)
Basically, the proposal I presented here had already achieved consensus in the prior discussion; it just hasn't been implemented yet. Cheers! bd2412 T 16:42, 26 September 2013 (UTC)
Right, there is broad consensus for your proposal, and I was tasked with implementing it, as I support the requested moves process as user:RMCD bot operator and template coder. I agree there is merit to the suggestion. I do see a minority of proposed mergers that might benefit from this. But I feel it's only a partial solution to the issues in merger-land. I'm still analyzing how we got to this place, in search of more robust answers. Peek at my user sandbox if you'd like to see where I'm at so far; I need to get back to that. As well as merge the merge-help pages. Wbm1058 (talk) 21:15, 26 September 2013 (UTC)

Is preview slower than usual?

I don't know whether it's just me, but preview has been slow for me recently (perhaps the last week or two), and seems to be getting slower every day. Has anyone else noticed this? SlimVirgin (talk) 20:31, 24 September 2013 (UTC)

Yes. Yes it is. Saving is actually even slower than previewing for me, but both have shown a slowdown in the last few days at least. equazcion | 20:34, 24 Sep 2013 (UTC)
Noticed also, I had been running a bot in the last few days and noticed several times huge slow down. --NicoV (Talk on frwiki) 21:25, 24 September 2013 (UTC)
I've also had a few instances (again, in preview) where only the top of the page has loaded, and I've had to wait a minute or so for the rest of it to appear. SlimVirgin (talk) 22:23, 24 September 2013 (UTC)
I have experienced a version of this today. In the edit window, the text initially loads, but wikEd takes it sweet time. Sometimes wikEd loads on part of the window and a lot below that is plain HTML style. Editing has been getting slower over the last few days. I'm so glad to see this post, because I keep running my anti-virus software to see if it's in my system. Except I don't have this problem on any other website. — Maile (talk) 22:42, 24 September 2013 (UTC)
  • That seems to happen when editing unusually large pages; it happens to me almost every time I edit, say, a "xxxx in sports" article - even when section editing - but the edit does take despit ethe error page. Given the size of that page though it shouldn't be the problem - and I got the exact same result on it. The Steele pic though loaded at normal speed. Apparently it's something making its way through the tubes... - The Bushranger One ping only 11:06, 25 September 2013 (UTC)
Things seem to be back to normal for me since late last night, fyi. equazcion | 13:36, 25 Sep 2013 (UTC)

Things still seem slow to me now. I just did a couple of edits and saving them took a lot longer than usual. On the other hand, just loading the main page is pretty quick at the moment, so some things have gotten better. Mudwater (Talk) 18:02, 25 September 2013 (UTC)

Pages are still slow to load for me today, especially preview and after saving. SlimVirgin (talk) 20:33, 25 September 2013 (UTC)
equest: POST http://en.wikipedia.org/w/index.php?title=Golden_Eagle&action=submit, from 10.64.0.133 via cp1018.eqiad.wmnet (squid/2.7.STABLE9) to 10.2.2.1 (10.2.2.1)
Error: ERR_READ_TIMEOUT, errno [No Error] at Thu, 26 Sep 2013 11:16:21 GMT Nurg (talk) 11:21, 26 September 2013 (UTC)
How come I could save the message above but I still can't save Golden Eagle? Nurg (talk) 11:24, 26 September 2013 (UTC)
Actually, I see in another tab that it did save, so why does it keep acting as though it has timed out? Nurg (talk) 11:43, 26 September 2013 (UTC)
After your save has been processed, it then needs to re-render the page and send you back a copy of the newly-rendered version. The timeout probably happening during that re-rendering process. --Redrose64 (talk) 13:51, 26 September 2013 (UTC)
  • This problem is recurring still today. Yesterday morning it was fine for me. As the day progressed, it got slower and too frustrating to even deal with by the end of the day. This morning, it was fine. As of the last hour, it's beginning to slow down again. Must be something happening at Wikipedia somewhere that it's fine during certain hours and then bogs down as time progresses. — Maile (talk) 14:44, 26 September 2013 (UTC)

General thoughts about Wikipedia's editing design

I've been thinking a bit recently about the design of Mediawiki and its relationship to the editors at Wikipedia and the WMF's usability initiatives. The heart of the problems with the rollouts in recent years is that the needs of modern editing are starting to stress Mediawiki past the limits of its original design. Mediawiki was originally designed under the idea that edits would be made in a serialized fashion to flat text files. This was its central concept. We can't forget that. Today we are tacking-on many things not within the scope of the original design: a WYSIWYG editor, a modern commenting system, notifications, article feedback, and so on. Their motivation is easy to understand: they want to make editing accessible. A lot of the editor hostility towards these feature implementations stems, I think, not from user intrinsic dislike of the features but from the awkwardness that arises from trying to make them work within the original design. In some sense, editing at Wikipedia is turning into a Frankenstein monster bolted together with ugly stitches showing.

We used to be like the red square. We are currently more like the purple shape. What we want to be like is the blue circle.

Programmers inspired by the idea of serialized editing of flat text files will start to work on software to implement this idea. This is how Mediawiki was born. To their credit they did a fine job. There are however major issues that arise with serialized-based editing, e.g., the ability to edit the entire file (something often just fine for the articles but not so good for the talk pages) and edit-conflicts. These aren't naturally solved within the original framework. Solutions have to incorporate workarounds or hacks that software designed with the goals from the start wouldn't have to do. I'll illustrated this point graphically at the right. The idealized "perfect software" based on flat text file approach is represented by the red square. The idealized "perfect software" based on the features we now want from wiki-editing software is represented by the blue square. What you get if you try to mix the two approaches by starting with the flat text file design and then bolting-on the "Web 2.0" features is represented by the purple polygon.

What is needed is a totally new Mediawiki developed from the ground up and planned with modern features in mind using the years of years of real-world editing experience we have accumulated. This new beast would satisfy the WMF's goal of a sleek "Web 2.0" interface while making the users happy at the same time. The original concept of Mediawiki was pure and simple and could reasonably be implemented by a small, passionate team. I suppose this could still be done but more realistically the complexity of a new Mediawiki implementation would need the resources and dedication of a professional team. I think this despite being aware of the risks normally associated with "rewrites"; in our case, the need is there and real and there's less pressure to set unrealistic goals and schedules.

Such an endeavour would require discussion and planning but I think the big picture of what the new software would look like is already in the air. I think the hardest problem of all is that of edit-conflicts. It's not clear to me that a "perfect" solution to this problem even exists: existing proposals are only semi-satisfying it is safe to say. Other problems such as the obtuseness of our talk pages have very elegant solutions just waiting to be used. In hindsight, the flat text file design along with archiving of stale discussions is a pretty bad idea. Thread-based discussion similar to those used on successful social media sites is clearly the logical format that talk pages "want" to be in. (I'm sure the new Flow system will incorporate some of those ideas so I'm curious to see how it works.) But as I discussed above, coding such modern features while retaining some measure of backwards compatibility is hard to do elegantly. We editors are building an encyclopaedia that hopefully will be used hundreds (billions?) of years in the future. It deserves editing software that is as perfect and intuitive as possible. That kind of elegance in software may not be achievable by continuing to "patch" Mediawiki.

This is my interpretation of the current state of Wikipedia/Mediawiki development. I'm proposing nothing serious here. But chit-chatting. I'd be curious to hear your "high-level" version of affairs and how you'd go about things if you were "ruler of the universe". Jason Quinn (talk) 18:10, 25 September 2013 (UTC)

Well...go do it. Or are you more of an idea rat? ;) Writ Keeper  18:14, 25 September 2013 (UTC)
:-)
Jason: It's "MediaWiki", not "Mediawiki". You only get to lecture about its deficiencies and how it could be so much better after you learn how to spell it. ;-)
While UseModWiki stored information in text files, MediaWiki as we know it never did. The only discernible point I could find in your post was a dislike of edit conflicts. Most edit conflicts occur on a few high-traffic talk pages. As you note, a modern discussion system will alleviate these. I'm not sure what else is actionable here.
Though it's easy to criticize MediaWiki (and frankly you missed or overlooked most of the true pain points of MediaWiki), we should note that MediaWiki has served as the platform of Wikipedia and its sister projects for over a decade. Each month, Wikimedia wikis receive hundreds of millions of page views, powered by MediaWiki (and very robust caching layers!). MediaWiki is a major contributor to Wikimedia's success to date. If you see specific problems within MediaWiki, you're strongly encouraged to file bugs at <https://bugs.mediawiki.org>. A rewrite is a non-starter, particularly without a very clear vision of what currently works and what needs improvement. --MZMcBride (talk) 20:37, 25 September 2013 (UTC)
P.S. And anyone who thinks Wikipedia will survive billions of years is a fucking moron. No offense intended, of course.
MediaWiki is as solid a tool for encyclopedia browsing and code-based editing as it ever was, and I don't think it would be a good idea to re-write it just to incorporate the other things we now need to do. Taking what we have and developing other things as separate modules as we go is pretty sound logic, I think. But at the same time I'm actually not entirely sure we're up to the task of pumping out the tools we need with the completeness, reliability, polish, and ease of use that'll be required, if we attempt to build them from the ground up ourselves. Each of these things (threaded discussion boards and a wysywig editor) are massive long-term undertakings that take a lot of time even for corporate developers who focus solely on one or the other. Here we're a nonprofit thinking we can crank these things out ourselves just because our site needs them. I dunno. It seems almost arrogant. As far as a discussion system, there seems to be an obvious answer that I'm assuming was deemed infeasible since it's so obvious and I haven't heard anything about it: Just use one of the many things already out there, like phpBB. I'd actually rather steal one of those than dream of building something from the ground up now that essentially does what they've been doing and refining for a decade. I'm not sure what the legal ramifications are, but technically I don't think it's all that farfetched to modify such things for use within MediaWiki. PS. User:Writ Keeper gets points for making a Dilbert reference :) equazcion | 20:39, 25 Sep 2013 (UTC)
mw:MediaWiki 2.0. Legoktm (talk) 20:42, 25 September 2013 (UTC)
  • (i) I don't see any problem with an underlying text-based data format for articles. The underlying data has to be in some format, and there are many benefits to this being one that can be read and edited directly. (ii) How many of the problems with "Visual Editor" are to do with trying to implement it in a browser, and how many just due to the intrinsic difficulty? 86.160.220.63 (talk) 23:01, 25 September 2013 (UTC)
  • Numerous advancements could be made with current format: This topic should be discussed at the idea lab wp:VPIL, or another page, but there are many new features which could be considered, including:
  • set some parts of a page as "protected sections" to require trusted access;
  • stop adjacent edit-conflicts by fix diff3.c to accept zero-line separation;
  • stack multiple replies/inserts at same line in LIFO order (last-in, first-out) to reduce edit-conflicts in lists or talk-pages;
  • have edit-Save read lock the page to prevent same-minute overwrite by next editor;
  • set template sections to run "<previewonly>" to show warning messages only during edit-preview, but not in live articles;
  • show proofreader's marks only in edit-preview (perhaps via "<previewonly>" tag);
  • implement a page-footer which could display a footer note from inside a template;
  • create a paragraph-editor which selects only 1 paragraph to edit (among all marked "[e]"), but have option to expand to full-page edit and insert the changed paragraph.
  • add syntax checker button in edit: [Show preview] [Show changes] [Check syntax];
  • show links to 4 "recent revision dates" during edit-preview, to warn of frequent other updates;
Those are just a few ideas, to provide a reply in this thread; however, a larger discussion should be held at wp:VPIL or elsewhere. I think there are many possible new features which could make the wikitext source editor much better. Wikid77 (talk) 15:37, 26 September 2013 (UTC)
On the subject of features to make the text editor better, what happened to colour-coding in the edit window to highlight syntax structure, similar to what is done in programming-language editors? This was mooted once, and would be a significant benefit IMO. Or is it another thing that I don't see because it is not available in IE? 86.171.43.177 (talk) 19:35, 26 September 2013 (UTC)

A couple times lately when I make edits in rapid succession

I get logged out and an error stops my edits saying: "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in". What causes this? Is it being worked on? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 20:36, 25 September 2013 (UTC)

This sounds like #Loss of session data. --Redrose64 (talk) 23:06, 25 September 2013 (UTC)
Thanks. It's now off to the archives for the curious. I wonder if this is something that could be improved upon on WMF's end. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 15:03, 26 September 2013 (UTC)

Are double redirects still being fixed by bots?

I've noticed that the redirect bots are working a lot more slowly than usual, if they are working at all. This could become extremely problematic in the event of page moves when disambiguation pages are created. Does anyone know why User:AvicBot and User:AvocatoBot have not been working lately? --Jax 0677 (talk) 22:42, 25 September 2013 (UTC)

See #Cached special pages not being updated below. Wbm1058 (talk) 20:54, 26 September 2013 (UTC)

Forced secure connection...again...

Even though the "always use a secure connection" box is unchecked, I'm being redirected to https:// no matter what I do on each and every page. This is becoming bothersome. - The Bushranger One ping only 22:43, 25 September 2013 (UTC)

Which browser are you using? If Firefox, try zapping all the forceHTTPS cookies, as suggested a few weeks back. --Redrose64 (talk) 23:09, 25 September 2013 (UTC)
I'm using FF22. I tried that - but there was no forceHTTPS cookie after I logged out per the directions there. There was one that existed while I was logged in, and I deleted it while logged in - and was then able to navigate using http://...however, as soon as I signed out and back in again, I was right back stuck on https://. This is a Wikipedia issue, not a my-browser isssue, as it's force-feeding me the forceHTTPS cookie every time I log in, even though it was just fine on http:// this morning. - The Bushranger One ping only 23:25, 25 September 2013 (UTC)
I tried deleting and had similar problems - it's also force feeding me that cookie every time I log in. Why do the technical people have meddle so... and not tell us. Dpmuk (talk) 06:07, 26 September 2013 (UTC)
Reported on bugzilla —TheDJ (talkcontribs) 08:53, 26 September 2013 (UTC)
Yes, reported several times, apparently. I have the same problem in IE10. This is an ongoing concern for many reasons and the bug reports are piling up. I really don't have any philosophical problem with using the secure server, but I do have a technical problem that concerns the AutoComplete function, especially for forms. When I was logged in via HTTP (evidently no longer possible), I was able to add to a dropdown list for the Edit summary field. When I am logged in via HTTPS, that function is disabled. Since I do a lot of gnome edits that require the same edit summary, it is extremely frustrating to lose this functionality. The most frustrating thought is that this will be a low priority on the ever-growing bug list. How do I get this fixed in a timely manner? – Paine Ellsworth CLIMAX! 17:42, 26 September 2013 (UTC)
This is turning up with consequences in the "non-Wiki world" as well - the fellow who makes Irregular Webcomic frequently includes Wikipedia links in his (extensive) annotations, and today's suddenly turned up with an https:// prefix on its link instead of http://. - The Bushranger One ping only 18:19, 26 September 2013 (UTC)
See below. – Paine Ellsworth CLIMAX! 21:40, 26 September 2013 (UTC)

Names of tracking categories

I am proposing that Module:Convert be used to replace the convert templates (the proposal is here), and am attempting to resolve some outstanding issues. Is there a convention that tracking categories should have "Pages with" at the start of the name? I see that several systems use that procedure, but is it standard? The categories in question are shown at Module talk:Convert/Archive 1#Category names, and I would appreciate opinions there (or here). Johnuniq (talk) 11:57, 26 September 2013 (UTC)

I asked a similar question when the tracking categories for Citation Style 1 were set up. I asked that question at WT:CFD and, with the exception of one respondent, pretty much ended up talking to myself.
As far as I can tell there is no requirement to preface all category pages with "Pages with". In fact, that seems sort of pointless to me because category pages contain links to pages – there aren't, for example, category pages that contain links to citations in pages or, in your case, links to convert templates.
Certainly the category page should be named to reflect precisely the thing that is being tracked. On the category page one can elaborate if necessary as we did with CS1 – that was mostly a transclusion of the appropriate text from Help:CS1 errors.
So, my advice: Make your tracking category names terse and precise and don't include "Pages with" in the category name. The CS1 categories were never renamed largely because of apathy or indifference. It's still something I'd like to fix.
Trappist the monk (talk) 16:11, 26 September 2013 (UTC)
Thanks, that's a very interesting discussion you linked to, and your views mirror my thoughts. Johnuniq (talk) 03:31, 27 September 2013 (UTC)
There isn't anything specific mentioned at Wikipedia:Category names about naming for tracking categories. While ther are a number of categories that start with Pages with, looking at Category:Tracking categories, you will see that there are more there that don't start with that prefix although a lot of those categories do contain either the word articles or pages. But again it doesn't appear to be mandatory to include on of those words. -- WOSlinker (talk) 06:17, 27 September 2013 (UTC)

Scrolling past the bottom of the page...

I've never encountered this before but whenever I go to the PRISM (surveillance program) article I am able to scroll past the bottom of the page. I've closed my browser and opened it back up and manually went back to the article and the problem is persistent so it was not a one time deal. I took a screenshot where you can see that I'm at what should be the bottom of the page but the scrollbar on the far right you can see that I can keep on scrolling but nothing is there but white. Anyone have any clue as to what is going on or if this is a bug or something that can be rectified? Thanks, — -dainomite   03:58, 13 September 2013 (UTC)

  • The current version of the page works fine for me in Firefox for Mac 23.0.1. As always with reports of this sort, it helps to know what web browser you are using. It also helps to tell us which version of the page you were viewing by pasting in a link from the History page, if you know how to do that (right-click or ctrl-click on the date/time stamp in the View History page and choose Copy Link, then paste it the way I did at the beginning of this response). – Jonesey95 (talk) 04:17, 13 September 2013 (UTC)
    • This is happening for me too on multiple pages, including that one, with Chrome 29.0.1547.65. Other example pages where it happens: Roy Lichtenstein, Carolina Panthers. I already looked at the wikicode for both of those pages, as well as the nav footers used on them; whatever it is, it's not something obvious. Maralia (talk) 04:32, 13 September 2013 (UTC)
    • (edit conflict) My browser is SRWare Iron, version 27.0.1500.0 (201000). Actually that version history of the article it does it still, scrolling below the end of the article that is. If I have to provide anything else please let me know. thanks, — -dainomite   04:33, 13 September 2013 (UTC)
      • I think it has something to do with the {{reflist}} template. Removing those from the page eliminates the issue. PS. Tested in Chrome 29, I do experience it on that page, when the reflists are there. equazcion (talk) 04:51, 13 Sep 2013 (UTC)
      • PS. That particular page (PRISM (surveillance program)) has two reflists, and the main one (not the "notes" group) needs to be removed to fix the issue. Also note you can test this by merely previewing. equazcion (talk) 04:54, 13 Sep 2013 (UTC)
      • PPPPS. (or whichever one I'm up to) This seems to occur on every page with a long reflist -- and the longer the list of refs, the more space shows up below the page. It also does not occur when using the plain <references/> tag, but only when using the {{reflist}} template. equazcion (talk) 05:01, 13 Sep 2013 (UTC)
      • Inspecting the <ol class="references"> element in Chrome shows a height of 11656.015625px in the computed styles, which seems to be the reason for the long space. Not sure exactly what the cause of all that extraneous height is yet though. equazcion (talk) 05:22, 13 Sep 2013 (UTC)
  • (edit conflict) I see this in Chromium 29.0.1547.57. It appears that Chrome has a bug in its handling of -webkit-column-width where it is processing the absolute positioning of the 'cite-accessibility-label' elements before applying the actual wrapping of the references list, which means that these elements wind up well off of what would otherwise be the end of the page. These elements appear to have been added in this change to the Cite extension (as an attempt to fix T40141) which was deployed today along with 1.22wmf16.
    @Graham87 or anyone else who knows a11y: is there a sane way to do this rather than having a span with complicated CSS to try to take it out of the page flow? Anomie 05:38, 13 September 2013 (UTC)
    • Yes, by using WAI-ARIA labels, but that behaves inconsistently with screen readers and doesn't work with NVDA. I've been in contact with Marius about these accessibility changes; we first tried the ARIA labels until we found the aforementioned problems, which is why CSS was used. As an aside, do any such problems occur with changes to Template:Sfrac, where I used similar techniques? Graham87 06:53, 13 September 2013 (UTC)
    • Setting either widht or height (or both) for .cite-accessibility-label to 0px will clear the problem. Using anything else then 0px may cause any render engine to actually render the element, with the above as a result. Edokter (talk) — 10:06, 14 September 2013 (UTC)
      • Which also works in both JAWS and NVDA under the latest release versions of IE and FF, according to tests at User:Graham87/sandbox20. However WebAIM cautions against this approach because screen readers are meant to hide that content. Graham87 11:34, 14 September 2013 (UTC)
        • We should go what works. And WebAIM's method also works. So we are we using something (clip:) that does not work? Edokter (talk) — 14:30, 14 September 2013 (UTC)
          • The clip technique usually works perfectly. However, it appears that the WebKit engine used by the Safari browser, as well as its fork Blink used by Chrome and Opera, have a bug where combining it with absolute positioning with column-based layout with very long columns results in miscalculation and rending the invisible hidden labels offscreen. Other browsers don't seem to have this issue. The change linked by Hoo below is a workaround in the Cite extension, you can apply it to common.css here temporarily to get it fixed right now. I don't think the WebKit/Blink bug was filed yet, I'll see to it. Matma Rex talk 14:43, 14 September 2013 (UTC)
            • Slight corrections: "clip" has nothing to do with it. It's purely a matter of -webkit-column-width/-webkit-column-count plus absolute positioning of something inside. Also note that the issue still occurs with short columns, it's just that on Wikipedia the effect doesn't lengthen things more than the normal post-References content already does. Thanks for filing the WebKit bug, Matma; please link it from here when you do. Anomie 11:48, 15 September 2013 (UTC)

The main cause over here seems to be that the English Wikipedia uses multi-column references while I only tested with single column ones. https://gerrit.wikimedia.org/r/84201 should fix this. - Hoo man (talk) 14:10, 14 September 2013 (UTC)

Thanks for working on this. I'd just noticed the issue and I'd begun investigating. I'm glad someone else beat me to it. :-) --MZMcBride (talk) 15:00, 19 September 2013 (UTC)
I put the fix in Common.css in anticipation of the patch being deployed. Edokter (talk) — 20:04, 24 September 2013 (UTC)
@Hoo man: Is it safe to assume that since the "status" on the link you provided says "merged" that the patch went through? — -dainomite   22:49, 29 September 2013 (UTC)
Yes, the patch should be live here now - Hoo man (talk) 16:59, 30 September 2013 (UTC)

Wikipedia:Edit filter to detect Google Translator text

copied this from Wikipedia:Help desk --Frze > talk 11:31, 25 September 2013 (UTC)

span class="notranslate" onmouseover="_tipon(this)" onmouseout="_tipoff()

How is it possible to produce such errors? Which button was used?
[12] [13] [14] [15] [16]
Thanks. --Frze > talk 05:12, 25 September 2013 (UTC)

Hi Frze. This one is still a mystery to me, perhaps others can comment, but until then I am going to assume that the people that made these edits got their content by doing a copy/paste from a website, capturing everything including the JavaScript and HTML code. I don't think the MediaWiki software produced this by clicking any button on Wikipedia. I'm glad you reverted it. —Prhartcom (talk) 05:56, 25 September 2013 (UTC)
Hello —Prhartcom - I don't think that this is made by Copy and Paste, because I'm working on categories Pages with incorrect ref-formating/missing reference list, and this error already happened hundreds of times... --Frze > talk 08:36, 25 September 2013 (UTC)
Could this be yet another of the Visual Editor malware behaviours? Roger (Dodger67) (talk) 09:18, 25 September 2013 (UTC)
I think I may have solved the mystery! It looks like these IPs are perhaps copypasting text translated into English from Google Translate. If you take a look at this article discussing Google Translate, at the very end it says that "Upon copying the text ... I noticed that both languages were put onto the clipboard. Intrigued, I had a look at the source code ... both the original texts are included 'side-by-side' in the source code, with the original text enclosed between "google-src-text" <SPAN> tags," which is a lot like what we see in the examples you provided. Sophus Bie (talk) 09:19, 25 September 2013 (UTC)

This appears to happen if you let Google Translate to translate you a Wikipedia page, and then edit the page from the translated text out. Try and error ... --Frze > talk 09:51, 25 September 2013 (UTC)

Aha! That's pretty interesting! Do you think perhaps one of us should bring this issue up at WP:Village Pump (technical)? If you've run into it hundreds of times, then it's probably going to keep on happening. The quickest fix I can think of would be for someone to create an WP:Edit filter for edits that turn out like that. Sophus Bie (talk) 10:08, 25 September 2013 (UTC)

Tried and errored: It is impossible to edit the page from the translated text out directly in Google translator. Only by COPY AND PASTE from Google translator.
What I do is clearing up as little "Wiki Janitor" a lot (thousands) of petty minor ref-errors of other editors, pages with missing references list or incorrect ref-formating. I checked such errors and simply reverted (by <undo> or <rollback>), but User:Acalamari told me not to do so. They are good-faith accidents and should have been reverted with a proper explanation.
Now we know the cause of this errors. There is no need for action in my opinion. Is it very difficult to detect such errors automatically?? It's going to keep on happening. But if a filter can be programmed to detect: <span class="notranslate" onmouseover= and stop saving (like website spam filter) instead saying: Do not use Google Translator text. It causes errors. - it would be helpfull. Wikipedially Yours Frze > talk 11:08, 25 September 2013 (UTC) Sorry for my limited language skills.

  • Cannot prohibit Google Translate as a technical restriction: There are too many acceptable uses of text from Google Translate, such as alternative song titles in other languages, and so we cannot claim a technical reason to forbid it. In some objectionable cases, Google Translate might have been used to improperly generate text from a plagiarized section; however, other users have been translating original text from other-language wikipedias, to have English-language pages added/expanded here. Restrictions might have to be merely voluntary warnings written into various essays, such as "wp:About translating German Wikipedia" or others. I am not seeing a valid use of an edit-filter as a likely method. -Wikid77 14:57, 25 September 2013 (UTC)
Special:AbuseFilter/345 is the logical place for this. This filter catches a range of strange html added by various browser extensions. I've added "notranslate" to the search clause which should hopefully pick it up. --User:Salix alba (talk): 17:07, 25 September 2013 (UTC)
That ought to catch it. Thanks, Salix! Sophus Bie (talk) 00:45, 26 September 2013 (UTC)
Thanks too. BW Frze > talk 04:46, 26 September 2013 (UTC)

Google translator text detector is working well. --Frze > talk 13:45, 27 September 2013 (UTC)

>>>- not working well: see examples

--Frze > talk 05:44, 28 September 2013 (UTC)

How do you mean not working? It tagged both those edits which is what it is supposed to do. Do you want it to block the edit? That would need a separate edit filter.--User:Salix alba (talk): 13:18, 28 September 2013 (UTC)

http login issue

I currently have my preferences set to use http rather than https but now when ever I try to load a page it starts off showing me as not logged in and so not using my settings (I use monobook rather than vector so it's pretty obvious), then as logged in and showing the message "Central login You are centrally logged in as Dpmuk. Reload the page to apply your user settings." Reloading does not apply instead we just repeat the whole process over again. It appears to me that I'm having to be re-logged in every time I load a page using http. I'm using Firefox 23.0.1. Any ideas? Dpmuk (talk) 18:39, 25 September 2013 (UTC)

This sounds like #Cookie not being baked (log in annoyance). --Redrose64 (talk) 23:05, 25 September 2013 (UTC)
I'm not so sure they're the same thing. Anyway, this sounds exactly like the issue that should have been fixed in gerrit:85776. Not sure if that's deployed yet. --Jeremyb (talk) 05:02, 26 September 2013 (UTC)
gerrit:85776 appears to be deployed. However, see T56513: there may be a caching issue going on where the new Varnish caches aren't properly varying on the presence of the forceHTTPS cookie. BJorsch (WMF) (talk) 13:52, 26 September 2013 (UTC)
I'm having a similar issue over the last few days. It only involves Commons. Every time I shut down my computer, Commons logs me out. No matter even if it's just a quick "Restart" of my computer. Commons is reading that as logging off them. I've checked my Cookies, and I'm not deleting any that are for Commons. But I've been seeing a couple of new cookies incubator.wikimedia.org and login.wikimedia.org; however, I never delete those. My Preferences say I'm logged in on 37 active sites. — Maile (talk) 00:07, 27 September 2013 (UTC)
  • It's worse than I thought. It's not when I reboot my system that makes it happen. I just logged in to Commons. Looked at English Wikipedia in another window. When I came back to Commons, it had booted me out again. But only Commons. And my Preferences still say I'm logged in on 37 active sites. — Maile (talk) 00:58, 27 September 2013 (UTC)
  • Buggers! I just tested it again. Logged in to Commons. Clicked on a Wikipedia page. Came back to Commons, and it had booted me out. I'm not feeling the love from Commons anymore.— Maile (talk) 01:02, 27 September 2013 (UTC)
If you've ever felt an emotion besides "genocidal rage" when dealing with commons, consider yourself lucky. VanIsaacWS Vexcontribs 01:08, 27 September 2013 (UTC)
The "37 active sites" thing in Preferences is a count of the number of sites that have had your details (login ID, password, email address and a small number of other things) copied from your original Wikimedia site, see WP:SUL. It has no knowledge of the state of cookies on your machine. You'll find that "37 active sites" periodically increases, but almost never gets reduced. I suspect that if you click the Manage your global account link, and then refresh your prefs, the figure will jump. Mine currently shows "Your account is active on 152 project sites.", although I've edited on no more than 60 - I don't think I've visited more than about 10-15 others. --Redrose64 (talk) 10:19, 27 September 2013 (UTC)
Understood. But I did, upon your suggestion, click on Manage your global account link, and refreshed my prefs-nothing changed. It still says 37 active sites. Like you, that number does not reflect sites I've visited, which in my entire edit history is a mere tiny fraction of that number. I don't believe this is about my cookies, either. Including the two I added yesterday, my "allowed" list of cookies for Wikimedia include incubator.wikimedia.org, login.wikimedia.org, commons.wikimedia.org, meta.wikimedia.org, wikimedia. What am I missing, and why would this kick up in the last few days? Even with all those cookies, Commons logs me out everytime I look at another page. — Maile (talk) 11:54, 27 September 2013 (UTC)
At commons:Special:Preferences, make sure you have "Remember my login on this browser (for a maximum of 30 days)" checked, also make sure that the "Always use a secure connection when logged in" setting matches that on Wikipedia. If you need to change the latter, log out afterwards and log in again. --Redrose64 (talk) 14:12, 27 September 2013 (UTC)
Yeah, they were both checked in Commons preferences, so that isn't the issue. And when I login on Commons, "Keep me logged in" is always checked. This is very odd. — Maile (talk) 15:03, 27 September 2013 (UTC)
  • In regards to Commons, they must be working on something over there. There's a hiccup of sorts over there. If I go to that page, it loads as not logged in. After a few seconds, it automatically logs me in right in front of my eyes, and tells me "You are centrally logged in as Maile 66. Reload the page page to apply your user settings." I reloaded the page, and it shows me logged out, repeats the identical process of logging me in with the same message about being centrally logged in and needing to reload the page. It showed my skin preference as Monobook, but what I was seeing was Vector. I changed it to Modern skin and it showed it as saved. But it's still appearing in Vector. They must be jiggling the system over there.. — Maile (talk) 21:19, 27 September 2013 (UTC)

PAGENAME in edit toolbar

This one has made me scratch my head for months.

In the edit toolbar on the .js page, how do you add {{subst:PAGENAME}} to multiple sections of the same button?

Because when you add {{subst:PAGENAME}} to the .js edit toolbar page, then click the edit toolbar, the .js page shows up, not the name of the page...


Thanks! Igottheconch (talk) 15:30, 26 September 2013 (UTC)

I'm not completely sure what you're asking, but try replacing
{{subst:PAGENAME}}
by
{{" + "subst:PAGENAME}}
...or by
" + mw.config.get('wgTitle').replace(/_/g, ' ') + "
(use wgPageName instead of wgTitle if you want the namespace, like FULLPAGENAME. The .replace(...) part is not needed with wgTitle, but is with wgPageName)
πr2 (tc) 15:39, 26 September 2013 (UTC)
The easiest option may actually be to just add // <nowiki> in the first line of the JS, if that's what you mean. πr2 (tc) 16:39, 26 September 2013 (UTC)
hi pir! looks like we are following each other from wikiproject to wikiproject.
I found: https://meta.wikimedia.org/wiki/Help:Recursive_conversion_of_wikitext
thank you for your help! Igottheconch (talk) 16:48, 26 September 2013 (UTC)
DAMN. every time I edit my .js page, the "subst" disappears. Igottheconch (talk) 16:58, 26 September 2013 (UTC)
@Igottheconch: try adding a separate line to the beginning like this: // <nowiki>. Does that fix it? πr2 (tc) 17:08, 26 September 2013 (UTC)
Looks very promising pir. :) Igottheconch (talk) 12:59, 28 September 2013 (UTC)

VisualEditor weekly update - 2013-09-26 (MW 1.22wmf19)

Hey all,

Here is a copy of the weekly update for the VisualEditor project. This is so that you all know what is happening, and make sure you have as much opportunity to tell us when we're wrong and help guide the priorities for development and improvement:

VisualEditor was updated as part of the wider MediaWiki 1.22wmf19 branch deployment on Thursday 26 September. In the week since 1.22wmf18, the team worked on fixing bugs and stability improvements to VisualEditor.

You can now drag-and-drop elements other than just images - references, reference lists, templates and other "nodes" should all be moveable with the mouse. Blanking the contents of a heading, pre-formatted block or other formatting block now deletes the block rather than leaving it empty, which is consistent with how OpenOffice and Google Docs behave (bug 50254).

The page settings dialog was briefly broken in Firefox but now is restored (bug 54322). A bug that meant that unnamed references got their names corrupted on using VisualEditor has also been fixed (bug 54341). A regression in copy-and-paste which meant that copy-and-paste stopped working outside VE even once it was closed was corrected (bug 54375), and the functionality was fixed to allow pasting images in Firefox (bug 54377).

Links are no longer possible to be applied to images, as this isn't possible to represent in wikitext (bug 53151). A bug which means that VisualEditor selected both the "slug" (blank line) and the infobox at the start of an article on initialisation was fixed (bug 54446).

A complete list of individual code commits is available in the 1.22/wmf19 changelog, and all Bugzilla bugs closed in this period are on Bugzilla's list.

Following the regular MediaWiki deployment roadmap, this should be deployed here (for opted-in users) on Thursday 3 October.

Hope this is helpful! As always, feedback gratefully received, either here or on the enwiki-specific feedback page.

Jdforrester (WMF) (talk) 18:25, 26 September 2013 (UTC)

So, let's see, currently the dragging-and-dropping of images totally sucks in many major ways, so you are now going to enable it for infoboxes, references, and reference lists too? Seems rather ass-backwards to me... (by the way, since this isn't rolled out to here yet, I tried it on [17], which to my immense amusement contains tons of visible wikitext in the VE. Hypocrisy muych? Anyway, as expected, it sucks.)
I've set you (WMF) a challenge at [18]. It's solvable if you are creative, but it's hardly user-friendly... Fram (talk) 07:31, 27 September 2013 (UTC)

I have posted more feedback at WP:VEF, I'll repeat my most recent post here:

I finally found a MediaWiki page with references, and as could be expected but contrary to what was announced, reflists can not be moved.[19] Probably a good thing, but if even the official wmf announcements can't be trusted anymore as to what is includd and what isn't, then one wonders how much these things have been tested (assuming they have been tested at all).

Proposal: the WMF doesn't issue any updates, new versions, new rollouts, ... for the next 3 months, and then comes back with some seriously tested actual progress. Please don't bother us with weekly unreliable announcements of very dubious improvements, it will not create any goodwill at all. Fram (talk) 10:35, 27 September 2013 (UTC)

Hi Fram, there is no way for the VisualEditor dev team to hide.  :) VE is an open source project: any progress happens publicly in the MediaWiki / Wikimedia Tech context anyway. Release soon & release often + document your releases are just good OSS practices - why change them? I personally think that getting here all releases and the related documentation that all the rest are getting is a good thing. You can always ignore them. Meanwhile, others may want to keep using, testing and contributing to a better VE.--Qgil (talk) 19:11, 27 September 2013 (UTC)
... On the other hand it is very good that you put so much time testing. I tried to map the problems you describe with Bugzilla reports:
  • T50891 - Translate extension's <translate> and <tvar> fail to appear in extensiontags (PATCH_TO_REVIEW)
  • About dragging, looking at your challenge I believe you mean T53669 - Visual Editor: editing window does not scroll when dragging (ASSIGNED)
  • About reflists, probably T51981 - VisualEditor: Drag-and-drop of content (text, transclusions, references, …) to move it (ASSIGNED)
I'm going to mention your feedback there. Sorry for my ignorance: do you have have a username in Bugzilla? Thank you again for your feedback.--Qgil (talk) 23:18, 27 September 2013 (UTC)

"You can always ignore them". No, we can't. VE created thousands of problems on pages, without the editors wanting or even noticing those. Many manhours have been spent tracking these down and correcting them, but only some of them have since been prevented by the WMF VE updates. Now, they are introducing new ones (or expanding old ones). Furthermore, "document your releases"? They don't update the documentation, and the things they claim this release will solve are not correct, as a very short test proved. As for my "challenge", the dragging doesn't scroll is also a problem, the challenge though was to get a template like "languages" at the very bottom of the page. You can't do this by normal editing in VE (it's of course no problem in wikitext), you have to use tricks or workarounds.

Usually, in Open Source (or anywhere), new releases are made available, and users choose whether they want them or not. Not so here, the developers (the WMF) force them upon us, whether we want them or not, whether we let them now before that they are much too buggy and that they create more errors than they solve (like e.g. with this release). Thorough testing before you release is also a good practice, but one the WMF hasn't heard of, it seems. These aren't exceptional things I tested, these are normal editing practices. Why can I find them so soon on my own when the WMF apparently can't but feel that this is ready for release?

Have you people at the WMF (and please include WMF in your signature, it indicates your COI status as a "paid editor" more clearly) not learned anything from the last few months? Apparently not... And no, I'm not interested in Bugzilla, the treatment I have received there (and have seen others receive) from WMF people has thoroughly disgusted me. If you force releases upon us here, against our wishes, and with known bugs in them, then I'll complain about them here as well, until sometime finally changes at the WMF (the general culture, the interaction with the Wikipedia versions, the priorities, and perhaps some of the personnel as well). For the moment, you are not helping us at all, you are just a big nuisance. Fram (talk) 15:30, 28 September 2013 (UTC)

Fram, I can help with problems in Bugzilla (just like many others do). Please CC me in any report you feel you haven't been treated properly. Nobody is perfect in Bugzilla, just like nobody is perfect in wiki discussion pages. But still, Bugzilla is an efficient tool when it comes to handle (discuss, push, triage...) software bugs and feature requests. I can also help forwarding feedback originated here in Bugzilla (just like many others do). I cannot help discussing how new features are deployed to English Wikipedia since I'm just a humble "technical contributor coordinator" at mediawiki.org and surroundings, with no opinion and even less decision on this topic. Still, hopefully we can work together. :) I came here after seeing your edits at mw:Groups and I do appreciate the time you take testing. Thank you again.--Qgil (talk) 04:47, 29 September 2013 (UTC)
I hate the English "you" :-) Often, when I'm criticizing "you", I mean you at the WMF plural, not you personally. So e.g. "you are a big nuisance" wasn't meant to read "Qgil is a big nuisance", but "the WMF is a big nuisance" (wrt to VE, their releases, their interactions with us here), despite people from the WMF trying to interact positively. I don't know whether it makes my message more palatable, but rest assured that I am fed up with the WMF as an institution, and one or two people in it, not with all people there. Fram (talk) 06:59, 30 September 2013 (UTC)

This is now being discussed at Wikipedia:VisualEditor/Feedback#Visual Editor/Status. Apparently no one at WMF / MediaWiki believes it important that these status reports are factually correct. Fram (talk) 15:51, 30 September 2013 (UTC)

I really don't see how a personal consideration that "people who wrote the reports should be the ones correcting them - except if they ask someone else to" can be read the way you read it, but anyway I'm here only to update a status of a bug mentioned above :) --Elitre (talk) 17:18, 30 September 2013 (UTC)
Well, what if the "people who wrote the reports" are not inclined to? Do they WP:OWN that page? Apparently they do, and no one else is allowed to alter these pages. Or does everyone at MediaWiki simply agree that these "press releases" are just that, PR, and shouldn't be correct. If so, then please don't bother posting them here anymore, we don't use VE anyway and don't trust the WMF anymore, so... 18:25, 30 September 2013 (UTC) — Preceding unsigned comment added by Fram (talkcontribs)

Security On Wikipedia

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


What type of security/anti-hacking programs does Wikipedia employ to safeguard against various types of attacks, and being a free website that doesn't use any ads how are they are able to do that? As far as I know Wikipedia has never been hacked or shut down or anything like that. One more question I was always curious about is if someone was an experienced hacker would they have the ability to hack into Wikipedia and obtain the IP address (or other information) of a registered user? Thanks for Wikipedia. BikeRider95 (talk) 19:35, 26 September 2013 (UTC)

Already asked on the help desk - please do not post the same question in multiple places. AndyTheGrump (talk) 19:39, 26 September 2013 (UTC)
Wait a sec, Andy, since when can't we post questions in more than one place? Show me a policy! – Paine Ellsworth CLIMAX! 20:36, 26 September 2013 (UTC)
I normally direct people to WP:MULTI. --Redrose64 (talk) 21:36, 26 September 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This is the technical village pump on the English Wikipedia. There are few better places to post such questions. We generally take the view that more information and transparency is better and that security through obscurity in design and development decisions should be minimized. I won't un-archive this discussion, but I've started a new one at User talk:BikeRider95. --MZMcBride (talk) 04:32, 27 September 2013 (UTC)

I don't know enough about the MediaWiki codebase to comment on specific security issues, but I do know that the WP:BEANS metaphor does not extend well to software security practices. Unless someone decides to post an open MediaWiki exploit (instead of reporting it to security@wikimedia.org), I can't see any harm in having this discussion here. — Mr. Stradivarius ♪ talk ♪ 11:08, 27 September 2013 (UTC)

Cached special pages not being updated

Just a quick heads up that there's a known issue where cached special pages, such as Special:DoubleRedirects (used by bots to fix double redirects), are not being updated. The relevant bug on Bugzilla is at https://bugzilla.wikimedia.org/show_bug.cgi?id=53227. wctaiwan (talk) 20:28, 26 September 2013 (UTC)

Aha, that likely explains the reason for the issue #Are double redirects still being fixed by bots? raised earlier here. Wbm1058 (talk) 20:53, 26 September 2013 (UTC)
Reply - Does anyone know when this might be fixed? --Jax 0677 (talk) 14:13, 27 September 2013 (UTC)

AutoComplete – forms

In Internet Explorer 10 the AutoComplete function can be set by use of Tools → Internet options → Content → AutoComplete, click on Settings. Then you check/uncheck those items you want to AutoComplete. My "Forms" box is checked, which governs a dropdown box for the Edit summary field. I have found that this does not work when I login to Wikipedia on a secure server. There may be other forms that don't auto-complete, as well. Since I make many edits that require the same edit summary, the absence of the AutoComplete functionality is a dramatic slowdown for me. I don't mind having to login securely...

  • I do mind having to type the same edit summary over and over and over!!!

Any ideas that might help fix this? Please remember that this is not an HTTP vs. HTTPS issue so much as it is a...

You and so many others, but for me the Internet Explorer buries its competition, even with all its idiotic-syncrasies. I use Firefox and Chrome to check my edits, so it's not as if I don't know how to use them. IE lets me do so much more! Joys! – Paine Ellsworth CLIMAX! 14:13, 28 September 2013 (UTC)

Edit toolbar on by default?

I was wondering whether a user at the help desk's problem might be because they had turned off the preferences setting for "Show edit toolbar (requires JavaScript)". Anyway, I don't think that's the issue, but when I was playing around and set it to off to see what they might be seeing, I learned that turning it off does nothing; that the edit toolbar remains working regardless of whether the setting for it is ticked on or not. Am I seeing what everyone else is? If so, should we remove this from preferences since it does nothing and miselads people into thinking turning it off is an option?--Fuhghettaboutit (talk) 23:36, 26 September 2013 (UTC)

Did you purge your browser's cache after saving the setting? —EncMstr (talk) 23:42, 26 September 2013 (UTC)
Oops! It looks like the browser caching problem is described at WP:BYPASS. —EncMstr (talk) 23:45, 26 September 2013 (UTC)
Do you have "Enable enhanced editing toolbar" checked? I think it overrides that option. Matma Rex talk 23:43, 26 September 2013 (UTC)
Yes, I bypass my cache whenever I make any preference change as a matter of course. But also yes, you've found the issue, thanks. If you untick "enable enhanced..." then it does go away. So (in the voice of Emily Litella), never mind.--Fuhghettaboutit (talk) 23:48, 26 September 2013 (UTC)
This ticket is related. —TheDJ (talkcontribs) 09:06, 27 September 2013 (UTC)

Wikipedia's gender icons

This refers to the tiny color icon that displays next to your user page link when logged in. I see those are delivered with CSS base64 codes. Would it be possible for someone to point me to the base64 code for the female version of the icon? I can't seem to find it through the usual search means. Thanks :) (PS. I could obviously register a dummy account under a female persona and get it that way, but would rather not). equazcion | 02:21, 27 Sep 2013 (UTC)

Anyway, I didn't realize there were any females on Wikipedia, what with all the arguing and posturing and huffing and puffing and thumping of chests all the time. EEng (talk) 02:54, 27 September 2013 (UTC)

Recent studies have shown that there actually aren't any females on Wikipedia. Probably why the icon depicts a middle-aged bald white guy for everyone. It could probably use some glasses too. equazcion | 02:59, 27 Sep 2013 (UTC)
Oi. I may be middle aged and white, but I am neither male nor balding. But I'll be darned if I'm gonna put an icon anywhere. The female versions always have terrible hairstyles. Risker (talk) 03:06, 27 September 2013 (UTC)

Since we're on the subject of sex, I'm gonna use that as an excuse to link to a bit of whimsy I'm somewhat please with, if I do say so myself. [20] In case it's not immediately apparent, the inspiration was the novelty of a bot leaving a Talk message for another bot. EEng (talk) 03:18, 27 September 2013 (UTC)

That's nothing; bots have edit-warred against each other - and even against themselves! - The Bushranger One ping only 07:46, 27 September 2013 (UTC)

CSD entries

 Done There are a number of Korean subway stations articles in Category:Candidates_for_speedy_deletion#Pages_in_category

Such as Jongno 3-ga Station but it is not clear to me why they are there. Anyone know?--SPhilbrick(Talk) 10:43, 27 September 2013 (UTC)

Was Template:Seoul Metropolitan Subway stations tagged for speedy? Werieth (talk) 10:45, 27 September 2013 (UTC)
There was a maintenance move involving Template:Seoul Metropolitan Subway (now a redirect). That may be the issue, Is this something that will go away with a little time, or do I need to do something to clean up?--SPhilbrick(Talk) 11:05, 27 September 2013 (UTC)
You can make null edits to the pages to force the categories to update. I just did that for all of the likely-looking pages in CAT:CSD, and the list has now shrunk quite a lot. If you don't make null edits, you have to wait for the job queue to process them, and that can sometimes take days or even weeks. — Mr. Stradivarius ♪ talk ♪ 11:19, 27 September 2013 (UTC)
OK, thanks. That looks like it cleaned it up --SPhilbrick(Talk) 11:23, 27 September 2013 (UTC)
(edit conflict) Also, yes, that is the issue. :) If a category is updated by a template, rather than directly by an edit to an article, the category page doesn't change straight away but has to wait for the job queue. This is to stop the site freezing when some editor just decides that he wants to make a change that requires 7.6 million pages to be updated. — Mr. Stradivarius ♪ talk ♪ 11:27, 27 September 2013 (UTC)
OK makes sense.--SPhilbrick(Talk) 12:00, 27 September 2013 (UTC)
I was going to ask what a null edit was, but I found a left over station at CSD. Now I know what a null edit is. :-) Peridon (talk) 16:38, 27 September 2013 (UTC)

How exactly bots/nobots templates work

Can someone who is familiar with how bots tend to implement {{bots}} and {{nobots}} directives (especially those that use "mwparserfromhell") please check out my question at Template talk:Bots#Whether this needs to be a "real" template call? Thanks. - dcljr (talk) 14:29, 27 September 2013 (UTC)

Disabling bot edit notifications

Is there a way to change the settings so that no upper right corner notification appears when a bot posts on my user talk page? I want my notifications to be things that require my attention, not the new issue of the signpost. There may not be a way to do that, but I figured I'd ask anyway. Howicus (Did I mess up?) 15:04, 27 September 2013 (UTC)

Instead of asking for the signpost to be copied to your talk page, you could add Wikipedia:Wikipedia Signpost/Templates/Issue to your watchlist. That might be less obtrusive. -- John of Reading (talk) 16:50, 27 September 2013 (UTC)
Signpost is delivered by EdwardsBot (talk · contribs). Echo-blacklisting it would be unpopular, I'm sure. I use a technique similar to that suggested by John of Reading - I have several user talk pages on my watchlist, nine or ten of which happen to be subscribers to Signpost. I just read one of those - it's a bit like reading somebody else's newspaper over their shoulder when you're on the train. --Redrose64 (talk) 19:55, 27 September 2013 (UTC)
I'm sure it would have to be something discussed by the community. Those that still wanted the notification would still have that option via Special:MyPage/Echo-whitelist but adding it to the site blacklist would prevent those that do not want it from having to deal with it. I think this is definitely something that should be considered since the operator of EdwardsBot refuses to make it exclusion compliant. Technical 13 (talk) 20:10, 27 September 2013 (UTC)
Regarding "exclusion compliance," if you don't want to receive The Signpost, unsubscribe from receiving it. It's an opt-in newsletter. If you do receive it, you're going to get a notification about it, as the bot will edit your talk page. This is completely expected behavior. --MZMcBride (talk) 20:23, 27 September 2013 (UTC)
MZMcBride, I was saying that the rest of the system should adapt to accommodate EdwardsBot, and I apologize if it seemed otherwise. Making the bot compliant would not prevent them from getting notifications specifically, it would prevent them from getting and posts from the bot what-so-ever, and I am not promoting that. I'm just saying that the community should have to opportunity to determine if they should get double notifications (the actual post and the notification there was a post) for such things. Technical 13 (talk) 20:33, 27 September 2013 (UTC)
Well, I was looking to disable the notifications for every bot (Edwardsbot was just an example), so that the notification would only show up when a non-bot editor posted...looks like the answer is no, but thanks anyway. Howicus (Did I mess up?) 15:58, 28 September 2013 (UTC)

Good article nominations have crashed

WP:GAC appears to have crashed. Once we get to Natural sciences, the list display "Template:GANentry". Could be bot-related, further discussion also here. CR4ZE (t) 15:12, 27 September 2013 (UTC)

I can confirm this now as it is listed on Category:Pages where template include size is exceeded as is Wikipedia:Good article reassessment/Archive 38 and Wikipedia:Good article reassessment/Archive 51. Looking to see what templates you are using and if we can make you a new one to cut down on meta template dependencies which should reduce or eliminate this issue. Technical 13 (talk) 15:21, 27 September 2013 (UTC)
Okay, so I created {{GANentry/sandbox}} in which I ran through a series of substitutions which resulted in this change to {{GANentry}} which has fixed the immediate problem. The pages is now at about 64% of the template include size limit. That being said, there is now a larger concern that the page is at 98% of the Expensive parser function count limit. Technical 13 (talk) 15:38, 27 September 2013 (UTC)
Okay, the reason for this is because of the '''({{#ifexist:Talk:{{{1|Example}}}/GA{{{2}}}|[[Talk:{{{1|Example}}}/GA{{{2}}}|discuss review]]|<span class="plainlinks">[//en.wikipedia.org/w/index.php?title=Talk:{{urlencode:{{{1|Example}}}/GA{{{2}}}}}&action=edit&editintro=Template:GAN/editintro&preload=Template:GAN/preload start review]</span>}})''' in {{GANentry}} which creates the (discuss review) or (start review) links on every entry. The members of the project should discuss an alternative to those links as #ifexist: is an expensive parser function. Technical 13 (talk) 15:49, 27 September 2013 (UTC)
It isn't so much something that's effecting me, I haven't opened any GANs recently. There looks to be a cumbersome backlog of GANs, not that that ever changes. I'd suggest that we split the GAN page into multiple pages, which I'm sure would require revamping Legobot but it would eliminate future problems where the backlog exceeds the technical limit. CR4ZE (t) 15:48, 27 September 2013 (UTC)
Part of the problem was this edit, which made {{la}} much more complicated than it had been before yesterday, and thus {{GANentry}} also became more complicated. If that edit were reverted, this change could be reverted too. --Redrose64 (talk) 20:05, 27 September 2013 (UTC)
Yes, Redrose64, that is likely the straw that broke the camel's back. However, if their system was on that fine of a line that such a change broke their entire system, then it was time for their system to be updated anyways. Also, that doesn't change the fact that they are less than a dozen entries away from exceeding the expensive parser function limit, which is about to break their system again. I've found the section on the projects talk page and offered my assistance to help them with that issue. Technical 13 (talk) 20:20, 27 September 2013 (UTC)

Is WPs unsecure site still working?

I suddenly cannot access the WP insecure site - neither by typing a http address, instead of an https, nor by clicking on my dozens of favourites - all of which start http - they automatically insert the s before loading.
Is this at the WP end? or have those "lovely" people in Seattle enforced another change, part way through a browsing session, without asking users if they want it, or telling users how to overcome it (W7 IE10)?
Why don't I use the secure site? Because I use dozens of pre-saved edit summaries, which do not work in https. Arjayay (talk) 16:06, 27 September 2013 (UTC)

Hi.
HTTP and HTTPS access should both work. There is an HTTP cookie in place that auto-redirects you from HTTP to HTTPS if you're logged in and have the "secure my session" user preference set in Special:Preferences.
Broadly, you should being using the secure site (HTTPS) unless you absolutely cannot. It should be possible to write a small JavaScript script that adds a drop-down menu (or autocomplete menu) to the edit summary field. Would that be sufficient? --MZMcBride (talk) 18:16, 27 September 2013 (UTC)
My "Preferences" are not set for "Always use a secure connection when logged in", but any HTTP address, as shown when hovering over a link in "favorites", becomes an HTTPS address as soon as it appears in the URL box.
A JavaScript script to add a drop down or autocomplete menu would be ideal, provided it remembers my previous edit summaries. As I understand it, part of the "security", is not to remember previous entries.
Arjayay (talk) 18:51, 27 September 2013 (UTC)
see above. According to Bugzilla this should be fixed in the next MediaWiki patch, scheduled for October 10. - The Bushranger One ping only 22:01, 27 September 2013 (UTC)
SO, it appears that, yet again, some half-tested (I am being generous) change has been made to the software, that disables a standard, and very important, preference, and we have to wait weeks for the damage to be undone? - No wonder we are losing experienced editors. Arjayay (talk) 19:01, 29 September 2013 (UTC)

Excluding template links from "Special:WhatLinksHere" has never been possible, and this limitation has been brought up before. But I seem to have done it for one page and I'm not sure how it happened.

I'm wondering if this is a glitch or what, because I'd like to be able to make it happen in the future :) equazcion | 19:32, 27 Sep 2013 (UTC)

It's just that the jobqueue hadn't caught up with the change you made to User:Equazcion/ScriptNav. A few null edits will fix it. -- WOSlinker (talk) 19:47, 27 September 2013 (UTC)
Aw. Oh well. Thanks for the explanation :) equazcion | 19:51, 27 Sep 2013 (UTC)

Spelling "correction" in editor

Recently I've noticed that when I'm editing Wikipedia, it automatic "corrects" my spelling. That is fine if I've made a typo, but it keeps correcting non-US English to US English spelling. Is this a Wiki function or a browser tool? It clearly contravenes WP:ENGVAR. And it's very subtle - initially I didn't even notice it to start with. --Bermicourt (talk) 20:18, 27 September 2013 (UTC)

Pretty sure it's your browser - most new browsers have built-in spellcheck. In Firefox, Options>Advanced will let you uncheck 'check my spelling as I type'. - The Bushranger One ping only 21:59, 27 September 2013 (UTC)
I've got "check my spelling as I type" switched on, but it doesn't alter any actual typed content - it puts wiggly red lines under words that it doesn't recognise, à la Microsoft Word. --Redrose64 (talk) 22:43, 27 September 2013 (UTC)
Bermicourt, If you're using Firefox, simply right-click in the edit box and select "Languages", then click on "English (United Kingdom)"; if it doesn't show in the list, select "Add Dictionaries" to download it (and any other languages you might want). I get squiggly red lines under misspelled words, but it doesn't actually change them (which would be very annoying, since it would change almost all wikicode) - (I also have "check my spelling as I type" turned on, like Redrose). Hope this helps. --NSH001 (talk) 23:43, 27 September 2013 (UTC)
Thanks folks. I'll look at that. I'm not against US spelling, but I like to choose it when I want it! --Bermicourt (talk) 08:03, 28 September 2013 (UTC)

URL stuff

Please see Help_talk:CS1_errors#Q for technical details. I'm bothered by the fact that a standard Google Books URL, which works without the "http://" part, produces an irritating error message (see here, for instance). My browser can read this just fine, so while another editor referred to this as "URL errors" they are clearly not errors. Can someone fix this please? Again, technical details are explained on the CS1 errors talk page; I could not possibly paraphrase that. Drmies (talk) 20:28, 27 September 2013 (UTC)

Relevant problematic code:
<ref>{{cite book|last1=Abdullaev|first1=Kamoludin|last2=Akbarzaheh|first2=Shahram|title=Historical Dictionary of Tajikistan|url=books.google.com/books?id=mC9RsIYy8m8C&pg=PA153&lpg=PA153|year=2010|publisher=Scarecrow|isbn=9780810860612|pages=153–54|chapter=Gurughli}}</ref>
I'm not sure it's unreasonable to say that the "url" template parameter be a full URL (i.e., include the protocol). Your Web browser automatically guesses which protocol you meant, but the protocol is still required. Perhaps the template should try to guess as well, but I'm not sure that's a great idea. --MZMcBride (talk) 21:02, 27 September 2013 (UTC)
Please can we keep discussion in one place? It started at Help talk:CS1 errors/Archive 1#Q. --Redrose64 (talk) 22:45, 27 September 2013 (UTC)
Yeah, well, I was told to take it here. I don't understand most of what these technical people are telling me and I'm not really sure I care. I just want those ugly notifications gone. Or, better yet, I want someone to fix the f***ing Citation expander for me! Drmies (talk) 23:07, 27 September 2013 (UTC)
I suggested that the discussion be moved here, since the poster's question is a technical one about how WP works, not a question about citations. I hope that someone here can explain the reason why WP does not or cannot guess at the protocol for a URL. If someone knows a good way to move the original discussion to this page, and that's the right thing to do, please do so. – Jonesey95 (talk) 02:25, 28 September 2013 (UTC)
I didn't mean that VPT should not have been informed: in fact, the first post above by Drmies was entirely in accordance with WP:MULTI. But once you get people discussing exactly the same problem in two different places, you get some people who read only the replies in one place, and so don't get the whole picture. --Redrose64 (talk) 08:01, 28 September 2013 (UTC)

Redirect labels

   These don't make sense together. Should the last should be changed?
-- FROM TOPIC

-- FROM TERM

-- TO TOPIC

-- TO TERM

 

This is a redirect from a related word.

Related words in an article are good candidates for Wiktionary links.

Redirects from related words are not properly redirects from alternative spellings of the same word but, at the same time, they are also different from redirects from a sub-topic, since the related word is unlikely to warrant a full sub-topic in the target page.

For more information, follow the category link.

In fact, should three of the template-pages contain Rdrs to one template? I only noticed bcz i previewed {{R from related term}} and {{R to related term}} before saving.
--Jerzyt 22:21, 27 September 2013 (UTC)

This isn't really a technical issue, but one for Wikipedia talk:Template messages/Redirect pages. --Redrose64 (talk) 22:50, 27 September 2013 (UTC)

Wiki loves monuments, disable?

I didn't mind seeing a few, what was it, weeks ago? But how can the community disable this godforsakenly annonying banner crap posted at the top of Wikipedia articles? What is the difference between this and advertisements? It has the same annoyance effect. Who determines when banners go up? Are we going to have to have an RfC with hundreds of people to disable this stuff? Or can someone just be bold? Are people without accounts seeing this stuff as well? Yikes. Our viewership has declined since the beginning of the year despite us adding about 900 pages a day. We shouldn't be chasing people away with these annoying advertising-like banners. Who determines the value of such advertisments? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 08:20, 28 September 2013 (UTC)

I'm not getting it. In Preferences - Gadgets I've got 'Suppress fund raiser banner' ticked - have you? May not be the thing, but worth looking until someone who really knows gets here. Peridon (talk) 18:21, 28 September 2013 (UTC)
I don't have it ticked. But who decides when to run these things? Where is the community input in this? Sorry to bug you again today User:Mdennis (WMF). Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 19:53, 1 October 2013 (UTC)
See m:CentralNotice, User:Biosthmors. :) --Maggie Dennis (WMF) (talk) 22:47, 1 October 2013 (UTC)

Discovered a problem with the format price template:

Looking at the template logic, this is because

  • {{#expr:(8.1*100 mod 10)}} is 0 (i.e. 0)
  • {{#expr:(8.2*100 mod 10)}} is 9 (i.e. 9)
  • NB {{#expr:(820 mod 10)}} is 0 (i.e. 0)

It looks like there's some sort of bizarre rounding error going on in the multiply. Is there a way round this? Edgepedia (talk) 10:06, 28 September 2013 (UTC)

    • got it! ->
  • {{#expr:((8.2*100 round 0) mod 10)}} is 0 (i.e. 0)

Edgepedia (talk) 10:09, 28 September 2013 (UTC)

VisualEditor Office Hours

The engineering department is hosting two office hours this week to discuss VisualEditor. The first of these will be held on Monday, 30 September, at 1900 UTC. The second will be held on Wednesday, 2 October, at 0000 UTC. Please join as Product Manager James Forrester discusses VisualEditor and upcoming plans. Thanks! --Maggie Dennis (WMF) (talk) 14:04, 28 September 2013 (UTC)

The link was correct, but the time for the first meeting should have read 1900. Sorry for any confusion! 24 hour time conversion threw me, I'm afraid. :/ --Maggie Dennis (WMF) (talk) 10:17, 30 September 2013 (UTC)

Problem logging in with API

I have a problem with logging in with a bot account using the MediaWiki API where it always gives the "NeedToken" result even if I pass the correct sessionID cookie and login token. The code used for login worked on 30 May 2013 when it was last used. Could the problem be because of any changes in the API login procedure since then? If yes, please mention the changes. If you need the code, the one currently used is at User:CLT20RecordsUpdateBot/Source/update.php and the code used for the 30 May edit is at User:IPLRecordsUpdateBot/Source/update.php. (both are similar except for a few changes such as user name, page title etc.) jfd34 (talk) 14:49, 28 September 2013 (UTC)

The name of the session cookie has changed, see this wikitech-l post. If at all possible, you really should redo your code to handle the cookies automatically from the Set-Cookie headers in the HTTP response instead of trying to construct them manually. Anomie 15:17, 28 September 2013 (UTC)

Official website template dead

On Forest Lawn Memorial Park (Hollywood Hills), the official website template isn't working. Why? It's just displaying the "Official Website" text as plain text, not a link. -- Zanimum (talk) 18:06, 28 September 2013 (UTC)

The URL contained = thus you needed to have 1= at the start. Werieth (talk) 18:09, 28 September 2013 (UTC)
Is this new? I've used the template for years without needing 1=! -- Zanimum (talk) 21:01, 28 September 2013 (UTC)
Two conditions must be met for 1= to be needed. These are fairly rare to both occur at the same time. The template must not be using a named parameter (IE url=, title=, name= ) and the value being passed must also contain a =. It has always been like this, PARAMETER = VALUE in this case PARAMETER = http://www.forestlawn.com/MainPark.aspx?park_id and VALUE = 4. Since the parameter is unknown in this case, its ignored. `Werieth (talk) 21:08, 28 September 2013 (UTC)
PS few official websites include = in the address. Werieth (talk) 21:10, 28 September 2013 (UTC)
(edit conflict) Or to put it another way, if a parameter's value contains an equals sign, you need to give the parameter name explicitly (even if that is a number). This behaviour goes right back to the introduction of named parameters in templates many years ago. See H:T#Usage hints and workarounds, first bullet.
If the actual URL had been http://www.forestlawn.com/MainPark.aspx, which does not contain an equals, {{official website|http://www.forestlawn.com/MainPark.aspx}} would have been perfectly valid. --Redrose64 (talk) 22:08, 28 September 2013 (UTC)
I always just use the 1= by default, I'm pretty sure on some older browsers it's needed, as I had problems without it without having those parameters both met. (Also, as an aside, people should be sure to use {{official website}} and not {{official}}, I see the latter used a lot but it just redirects to the former.) - The Bushranger One ping only 00:03, 29 September 2013 (UTC)
It's not browser-specific - or at least, it shouldn't be, because template parameter processing is done entirely on the Wikimedia servers - what your browser sees is pure HTML. With the 1= before the template parameter, the browser is served
<span class="official website"><span class="url"><a rel="nofollow" class="external text" href="http://www.forestlawn.com/MainPark.aspx?park_id=4">Official website</a></span></span>
which contains a link (it's the <a>...</a> element), but without the 1= the browser is merely served
<span class="official website">Official website</span>
which has no link, and is little better than plain text. Browser/HTML compatibility should not be an issue: the <a>...</a> element works in all browsers (it's one of the original elements of circa 1990), and whilst the <span>...</span> element is not original (it was introduced with HTML 4.0), you'd need to still be using a browser about as old as IE 3 for that not to be recognised. --Redrose64 (talk) 10:06, 29 September 2013 (UTC)
  • It's always been like that. You have options (and = isn't the only "naughty" character, | is just as bad). The options for = are to use the named parameter (ie. url=), use the exclusive numbered parameter (ie. 1=), or use the "escaped" = sign in the url itself (ie {{=}}). For pipe, the only options I'm aware of are escaped methods including {{!}} and &#124;. Happy editing! Technical 13 (talk) 22:04, 28 September 2013 (UTC)
    For the pipe character, you can (almost always) percent encode it as "%7C". This option isn't available for the equals sign (which would be "%3D"), because that removes its status as key-value separator for the target web server (i.e. www.forestlawn.com would see a parameter named "park_id=4" with no value). Anomie 11:36, 29 September 2013 (UTC)

Tracked template not working (again)

Can anyone figure out why {{tracked}} is not working here (on this page)? I can find no apparent error. Edokter (talk) — 22:35, 28 September 2013 (UTC)

Works for me. Theopolisme (talk) 22:56, 28 September 2013 (UTC)
I guess Edokter isn't thinking of the template itself but of the JavaScript actions it should cause for users with the gadget "Enable tracking bugs on Bugzilla using the {{tracked}} template." PrimeHunter (talk) 23:05, 28 September 2013 (UTC)
See User:PrimeHunter/sandbox2 for an example where it works for me. With the gadget enabled, the box made by {{tracked|54626}} displays the name and status of bugzilla:54626: "forceHTTPS session cookie placed even with HTTPS opt-out set RESOLVED". This text is made by MediaWiki:Gadget-BugStatusUpdate.js and not by the template itself. Above in #Is WPs unsecure site still working? I only see the same as your image: A box saying "Tracked in Bugzilla Bug 54626". PrimeHunter (talk) 23:20, 28 September 2013 (UTC)
It is the script that fails. I found some duplicate bugs that may cause the script to fail, but removing those did not fix it. Regardless, I found that the template (and script) uses ID attributes, which must be unique. I changed those into classes. See what happens. Edokter (talk) — 10:31, 29 September 2013 (UTC)
The problem is the link to T56598 in the section #Blacklist not functioning correctly. That bug was changed to be a hidden bug, which means Bugzilla's API throws a permissions error when asked to return it. It would be better if Bugzilla's API would do more like ours, and return the remaining results while indicating a permissions error for just that one bug, but I haven't looked to see if it's possible to tell it to do that. Anomie 11:31, 29 September 2013 (UTC)
Just found out myself... I've unlinked the bug. Edokter (talk) — 11:45, 29 September 2013 (UTC)

Editor on .js pages

I have just noticed that the editor on .js pages has changed when I tried to edit my monobook.js page. Sorry if this has already been covered, I don't edit js pages often. It's all very well having semantically meaningful colours in the edit window, but I am now having a problem finding things on the page. My browser search seems to be ignoring the edit window (FF23). It only finds text on the page that is not in the edit window. Is there some kind of built-in search facility in the editor? Or failing that, how do I get the old editor back? SpinningSpark 23:19, 28 September 2013 (UTC)

While in the new editor (when the editor box has focus, ie. there's a blinking cursor in it), the Ctrl-F keystroke brings up a custom search that will find things throughout the code. You can get the old editor back by clicking the leftmost button in the upper toolbar (the /* graphic). equazcion | 06:05, 29 Sep 2013 (UTC)

Slow to load

Am I the only one having trouble to load Wikipedia pages? Revision histories, undo, Previews, Saves etc are impossibly slow and reminiscent of when I had a dial up. I don't think it's me. I don't have problems with other sites that I know are big to load. SlightSmile 23:49, 28 September 2013 (UTC)

Could be a combination of HTTPS (instead of HTTP), and that the current scripting doesn't seem to allow the browser to display a partially-loaded page (as many of the older versions of scripting did)... AnonMoos (talk) 07:39, 2 October 2013 (UTC)

Recent changes/Medicine

There once was a bot maintained by Rich Farmborough that fed recent changes to medical articles (articles with Wikiproject Medicine's template on their talk page) into a page like a watchlist. Since Rich was blocked from bot work, it has fallen into disrepair (it now just lists changes to articles beginning with "A"). Is there an alternative way for me and others to monitor recent changes to medical articles? --Anthonyhcole (talk · contribs · email) 01:10, 29 September 2013 (UTC)

There's the WikiProject Changes tool at Toolserver.org.[21] Peter James (talk) 01:55, 29 September 2013 (UTC)
Yay! That's perfect. Thank you, Peter. --Anthonyhcole (talk · contribs · email) 02:27, 29 September 2013 (UTC)

How many editors are blocked indefinitely?

Is it possible to see how many indefinite blocks are out there currently, and/or have been given if the past? How about blocks in general? Is there any tool/list that tells how many blocks of various length are/have been given out? --Piotr Konieczny aka Prokonsul Piotrus| reply here 05:59, 29 September 2013 (UTC)

Special:BlockList shows all blocked users. It has an option to hide temporarily blocked users, which would only show indefinites. I'm not sure if there's a way to get total counts automatically. equazcion | 06:23, 29 Sep 2013 (UTC)
Yep, I was looking at it, but without total counts, it's a major pain to try to use it. I also looked at Category:Blocked_Wikipedia_users which gives about 150k, but I don't think it's accurate - many editors get blocked indef but don't end up in that category (I just compared some random indefs from block log and they are not in that category, for example User talk:Peterfedor or User talk:Josh miller135. --Piotr Konieczny aka Prokonsul Piotrus| reply here 06:31, 29 September 2013 (UTC)
Posting on behalf of Betacommand via IRC, the current count is 586809 accounts. Legoktm (talk) 22:54, 29 September 2013 (UTC)

Aggregate block statistics would make for a good database report. --MZMcBride (talk) 03:26, 30 September 2013 (UTC)

"Edit history stats"

On the left side of this (and I think every) page under "Statistics" is a bullet point "Edit history stats" that no longer works. If it can't be revived could someone please delete it? --Anthonyhcole (talk · contribs · email) 06:40, 29 September 2013 (UTC)

You're likely seeing that cause you have my User:Equazcion/SidebarHistoryTools script installed. I just removed the link to the now-defunct tool. You may need to bypass your cache to see the change. equazcion | 06:46, 29 Sep 2013 (UTC)
I realized after removing the link that there's a replacement for the defunct tool, so I added the link back pointing to the correct URL. Again, bypass your cache to see the change. equazcion | 06:50, 29 Sep 2013 (UTC)
...although I just checked your .js pages and don't see my script in them. I think the link you're seeing is coming from User:Smith609/toolbox.js, so you'd have to contact him to fix the script. But thanks for helping me update my script anyway :) equazcion | 06:55, 29 Sep 2013 (UTC)
OK. Thanks. If it's only happening to people who've optedd in, I guess it's not a problem. --Anthonyhcole (talk · contribs · email) 07:30, 29 September 2013 (UTC)

Remove article feedback enabler on all village pumps

I notice someone accidentally enabled article feedback on this Village Pump page. That should probably be removed, and all Village Pumps should probably have the enable feeback link disabled. I'm not sure how that's done, but WP:ANI doesn't show the link, so I'm assuming it's possible. equazcion | 07:23, 29 Sep 2013 (UTC)

That was me. Sorry. I couldn't immediately see how to disable it. --Anthonyhcole (talk · contribs · email) 07:27, 29 September 2013 (UTC)
No problem, I think it was bound to happen sooner or later with the link showing up here. I'm not sure how to disable it either, but I'm assuming an admin can. equazcion | 07:37, 29 Sep 2013 (UTC)
 Disabled through the "change protection" tab, see here. --Redrose64 (talk) 09:27, 29 September 2013 (UTC)
Thanks Redrose64. If possible it should probably be disabled preemptively for the other Village Pumps as well. equazcion | 09:29, 29 Sep 2013 (UTC)

JavaScript edit request

Could a kind admin who knows JavaScript take a look at the edit request over at User talk:Js/urldecoder.js#Support for LiquidThreads? It's been sitting in CAT:EP since September 25 and needs someone who knows what they're doing to take a look at it. — Mr. Stradivarius ♪ talk ♪ 14:37, 29 September 2013 (UTC)

RTL charcter

I am trying to fix the original upload log at File:Herzliyya skyline.jpg. I am trying to insert a right-to-left mark. I have failed. Can someone assist me with this? If we are successful, I may try to fix all the RTL errors in original upload logs by bot. Magog the Ogre (tc) 17:26, 29 September 2013 (UTC)

I added in a LRM and that fixed the username, dimensions, and file size from the original upload fixed. I don't actually read Hebrew, so I don't know if the rest of the description is correct, but the meta-data is legible at least. VanIsaacWS Vexcontribs 18:02, 29 September 2013 (UTC)

Where is .notice{color:#F00} coming from?

This style is present on my userpage, where it causes a hatnote to become red (hopefully it's not just me). I can't seem to find where it's coming from or why (it's not present in anything else that I've found); my element inspector suggests it's coming from index.php:4, which is the line that declares the character set and title, and contains no CSS, nor do any of the lines near it.  — TORTOISEWRATH 21:56, 29 September 2013 (UTC)

Which hatnote? --Redrose64 (talk) 22:09, 29 September 2013 (UTC)

I would need a tool or script or whatever that lists all the articles linked in a given article, and how many times is each one linked. I would need to locate the pages linked several times, and reduce the excessive links. I know that such a tool exists, I had once used it, but I don't remember the name or where to find it. Cambalachero (talk) 23:12, 29 September 2013 (UTC)

User:Ucucha/duplinks? PrimeHunter (talk) 23:18, 29 September 2013 (UTC)
It wasn't that one, but it was also useful. Thanks! Cambalachero (talk) 01:54, 30 September 2013 (UTC)
WP:AWB lists multiple links on pages as well. VanIsaacWS Vexcontribs 02:35, 30 September 2013 (UTC)

Database server lag of 40,654 seconds

I just saw a "Due to high database server lag, changes newer than 40,654 seconds may not appear in this list" notification when I clicked my watchlist. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 23:35, 29 September 2013 (UTC)

Same here. Looks to be slowly coming down, but its like a bomb went off with that ~40,000 second loss of edits. Special:RecentChanges looks to be going okay. Chris857 (talk) 23:37, 29 September 2013 (UTC)
I'm seeing the same thing. I assume they are doing some kind of work on the servers. --Tryptofish (talk) 23:40, 29 September 2013 (UTC)
Down to 35,875 seconds now. Holy database server lag, Batman. - The Bushranger One ping only 23:44, 29 September 2013 (UTC)
Looks to have cleared out fully for me, now. Chris857 (talk) 23:58, 29 September 2013 (UTC)
Seems to be gone for me as well, at least for now, but man that was one crazy database lag. Let's see if it continues.... Narutolovehinata5 tccsdnew 00:03, 30 September 2013 (UTC)

Will it be possible to use percentage for cropping rather then amount of pixels?

Template:Annotated_image : Will it be possible to modify the template input, such as using percentage rather then amount of pixels? e.g. crop 9% from the top rather then "-22" pixels?. I have used this template recently and the experience was rather inconvenient. thanks. Ykantor (talk) 01:13, 30 September 2013 (UTC)

Broken math formulas

Resolved

Somehow this edit broke all math formulas in Lucas sequence. This revision for me comes up as a red mess with a lot of error messages like the following:

Failed to parse (Cannot store math image on filesystem.): U_0(P,Q)=0, \,

Any ideas what's wrong here? -- Toshio Yamaguchi 11:19, 30 September 2013 (UTC)

The linked revision looks fine to me, for some reason. I don't see any red errors. equazcion | 11:25, 30 Sep 2013 (UTC)
Toshio, can you get us a screenshot and upload it to commons? I can't see any red or error messages either. Thanks. Technical 13 (talk) 11:33, 30 September 2013 (UTC)
Actually it was a server caching issue. A null edit fixed it. Thanks. -- Toshio Yamaguchi 11:35, 30 September 2013 (UTC)

Help!

1. I seem to have lost the 'edit history' tab at top right of the edit page. I think it happened when I was on my 'Preferences' page, (possibly using the 'Gadgets' tab); but I can't remember what I unchecked.
2. When I come across a link that I don't know, e.g. WP ETA; I hover the cursor/arrow over said link - and all I get is 'Wikipedia ETA'. I know that 'WP' is 'Wikipedia' !! (As the old saying goes: 'As much use as a chocolate fireguard'), but what does 'ETA' stand for? (I do know what it means, in this instance, I'm just using it as an example). Is there some way that this system could be changed to be of some use, because at the moment, it's of no use whatsoever.
3. Why, when going through the edit history page (when I can, see '1' above), do the 'radio buttons' for different versions of an article always revert to the most recent effort, even though I might be looking at a version of the page from many editions ago ? It didn't always 'function' in this silly way.

I use Internet Explorer 10.

Thanks in advance

RASAM (talk) 13:22, 30 September 2013 (UTC)

  • Some answers to the 3 issues: The MediaWiki software has been updated on a weekly cycle in recent months, and some functionality has been changed for various versions of various browsers. Specifically, your issue number (1): the missing "View history" tab has been noted by other users, so try widening the screen when the search-box ("[Search________]") seems to overlay and eclipse the history-tab or overflow-menu arrow underneath, or else overlays atop the page title; apparently, there is an extra, variable-size gap (auto-widens with screen width) between the "Talk" and "Read" tabs which has been pushing the other top tabs further to the right (and eclipsing tabs on some browsers). For issue (2), the hover text for some terms could be improved. However, for issue (3), about history-page radio buttons, I suggest viewing more entries per page, such as option "&limit=500" in the URL address line, and then the radio buttons to compare selected versions would not reset back to the top entries on the page, as often. Other users have suggested the developers create a stable version of the MediaWiki interface (as in "Classic Coke") for users who tire of the shifting, unpredictable screen appearance after weekly updates to the MediaWiki software. It gives the feel of the automobile's steering wheel and brake pedal being shifted each week. I guess it could be said the screen updates are "straightening the deck chairs on the Titanic" rather than fixing important problems, such as wp:edit-conflicts, or providing new features such as a footer box to display at the end of a page regardless of bottom edits to a page. Anyway, I am sorry the problems have annoyed you, but thank you for noting these concerns, as a reminder for what upsets users. -Wikid77 (talk) 11:46, 1 October 2013 (UTC)

Resetting passwords is far too unforgiving

I usually forget my password and have to reset it. I notice that it takes a tiny amount of login attempts (1 or 2) to trigger a red flag, forcing me to decipher capchas and wait five minutes, etc. It hits me every few weeks. Most people have more than 1 or 2 passwords which they try before remembering what they used. 4-5 attempts would be much more convenient. Notice that google and other "giants" are more lenient, so it surely would not make accounts noticeably less secure.J1812 (talk) 15:58, 30 September 2013 (UTC)

Dear editors: While checking out the above page in order to give advice to a new user, I clicked on the "Ask" button, but it doesn't appear to do anything. Since I came to the page from the default banner at the top of my talk page which says "Ask questions, get answers", this is surprising. —Anne Delong (talk) 17:16, 30 September 2013 (UTC)

Those buttons at the top of Wikipedia:Questions are actually more like navigation tabs. The "ask" button just navigates to Wikipedia:Questions in case you're at one of the other help pages -- so if you're already at that page, it indeed doesn't do anything. Might be kinda confusing. I may rename that button to something more intuitive, like "questions". equazcion | 17:25, 30 Sep 2013 (UTC)
Done -- made it "Where to ask questions". Hopefully that helps. equazcion | 17:30, 30 Sep 2013 (UTC)
Thanks. It was a little embarrassing to be saying to the user, "Look how easy it is to get help", and then the "Ask" button didn't do anything. —Anne Delong (talk) 21:36, 30 September 2013 (UTC)

Redirect disables back button

This morning, I added a redirect while on a Mozilla Firefox computer. When I tried to go back to what I was doing before, I kept being sent to the redirect target. I even clicked on the back button very quickly, which normally works in that situation. Nothing worked, so I had to retype the search term. I don't know whether this is something Wikimedia would consider a bug.— Vchimpanzee · talk · contributions · 20:32, 30 September 2013 (UTC)

I use Firefox. I've noticed for some time (over two years, I think) that if a redirect has a fragment identifier (i.e. it points to a section heading), I normally need to use "back" twice. --Redrose64 (talk) 20:53, 30 September 2013 (UTC)
But in this case it "redirects" no matter what I do. No amount of pressing the back button changes this.— Vchimpanzee · talk · contributions · 21:27, 30 September 2013 (UTC)
Which version of Firefox are you using? I'm still on 23.0.1, but I know that 24 has been released recently. --Redrose64 (talk) 21:44, 30 September 2013 (UTC)
If you hold down the Back button in Firefox, it should show you the last 10 or so pages in that tab's history. You can jump back two or three steps at once by clicking on the title of the page you want. – Jonesey95 (talk) 21:47, 30 September 2013 (UTC)
Yes, or you can right-click the back button for the same effect. --Redrose64 (talk) 22:07, 30 September 2013 (UTC)

I haven't asked what version. I should try these ideas if it happens again. But no one seems to be saying this is a bug.— Vchimpanzee · talk · contributions · 17:19, 2 October 2013 (UTC)

HotCat isn't working [for me]

For some reason my HotCat, despite being enabled in preferences, is not working and the bottom of articles is displayed as if HotCat weren't enabled. I tried resetting my preferences back to default and enabling HotCat by itself and that still didn't work. When I made this edit to my common js page didn't make any difference either but that was more my wondering "I wonder if this will do anything" more than anything else. My browser is SRWare Iron, version 27.0.1500.0 (201000). I don't think browser compatability is an issue since hotcat lists Google Chrome as "tested and working" and SRWare Iron is chromium based. Thanks, — -dainomite   22:18, 30 September 2013 (UTC)

Dainomite In your User:Dainomite/vector.js file, delete the first 3 lines (including the */). That should fix it. equazcion | 01:48, 1 Oct 2013 (UTC)
Awesome, thank you! I had no idea... — -dainomite   02:57, 1 October 2013 (UTC)
No problem :) equazcion | 03:31, 1 Oct 2013 (UTC)

wikidata seems not to send the wikilinks for the left column if I am not logged in as en:wi editor. --Best regards, KS (wat?) 10:44, 1 October 2013 (UTC)

It works for me. Try clearing your entire cache. What is your browser? Please give an example article. Are the links and language names not displayed at all? PrimeHunter (talk) 10:50, 1 October 2013 (UTC)
The ">languages ¤" link (at the left side) was sometimes closed when I logged out and reloaded the page I was viewing. But now I can't reproduce the failure. It is all right now. --Best regards, KS (wat?) 20:55, 1 October 2013 (UTC)
The languages list depends on javascript, and a typical Wikipedia page uses several .js files; like the CSS files, these don't come from the main Wikipedia servers at the domain "en.wikipedia.org", but a separate server at "bits.wikimedia.org". If a crucial one of these files fails to make it through from the bits server, the languages list may fail to display correctly - or at all. --Redrose64 (talk) 21:34, 1 October 2013 (UTC)

Centre alignment for article title

Hi I was wondering if somebody knew how to get the title of the article to be in the centre rather than the left?♦ Dr. Blofeld 11:17, 1 October 2013 (UTC)

If you mean making a particular title display that way for all users, I don't think we can currently do that. If you want to have all article titles display that way just for you, you can add this to your common.js file:
  • $('.firstHeading').css('text-align','center');
equazcion | 11:23, 1 Oct 2013 (UTC)
Why make it that complicated?
.firstHeading { text-align: center; }
in Special:MyPage/common.css will do it. --Redrose64 (talk) 11:32, 1 October 2013 (UTC)
As a js coder my brain defaults to js solutions. But yeah the CSS method is basically the same thing, and is probably more "appropriate". equazcion | 11:48, 1 Oct 2013 (UTC)

Thanks for the quick response!♦ Dr. Blofeld 12:34, 1 October 2013 (UTC)

  • Also DISPLAYTITLE allows span alignments: An individual title can be shifted by using a span-tag when styling the page title:
  • {{DISPLAYTITLE:<span style="margin-left:4em">Xxxx</span>}}
However, the same style would apply when editing the page, to display extra spacing at the top: "Editing Xxxx". Anyway, there might be cases where the span-styling of the title would be more appropriate, such as for a rock band name with multiple fonts.
  • {{DISPLAYTITLE:RockBand<span style="font-family:Georgia">789</span>}} → RockBand789
Things to ponder. -Wikid77 12:41, 1 October 2013 (UTC)

So what would be the full coding for a centrally aligned slightly boldened/largened Georgia font for article titles?♦ Dr. Blofeld 13:44, 1 October 2013 (UTC)

In order that the font size can be relative to the normal size for a first-level heading, you need to do it as two rules instead of one:
.firstHeading {
  font-family: Georgia, sans-serif;
  font-weight: bolder;
  text-align: center;
}
.firstHeading span {
  font-size: larger;
}
I've put each declaration onto a separate line for clarity - you can run them together onto one line if you like; the only mandatory space is the one before span Again, this goes in Special:MyPage/common.css. --Redrose64 (talk) 16:34, 1 October 2013 (UTC)

Missing gadgets

I think I had a gadget allowing to see the number of rights, edits, etc. of a contributor and the content of a diff when hovering over the watchlist, but it's gone. I am also looking for a gadget allowing to see the references when editing a section. Thanks, — Racconish Tk 13:33, 1 October 2013 (UTC)

I'm pretty sure that you're thinking of Wikipedia:Tools/Navigation popups, which is the seventh gadget in the list on the preferences page. ​—DoRD (talk)​ 13:42, 1 October 2013 (UTC)
Right on, thanks ! Does the one on references ring a bell ? — Racconish Tk 15:02, 1 October 2013 (UTC)
There is a popup for references, it is at Preferences → Gadgets - last item in the "Browsing" section, "(D) Reference Tooltips: hover over inline citations to see reference information without moving away from the article text (does not work if "Navigation popups" is enabled above)". However, it's only active in the page view, not in the edit window.
Viewing the refs when editing a section has been a wishlist item for years. What some people do is to put a dummy <references /> at the bottom of the section, and preview it. Make sure that you remove it before saving. --Redrose64 (talk) 16:47, 1 October 2013 (UTC)
Thanks Redrose. I was looking for an equivalent of this gadget. Cheers, — Racconish Tk 17:26, 1 October 2013 (UTC)

More server issues...

Twice this morning I've had 'invalid token' errors while trying to use Twinkle to apply templates to usertalkpages, and just now I got a 'Grabbing data of earlier revisions: Exception Caught: DB connection error: Can't connect to MySQL server on '10.64.16.10' (111) (10.64.16.10)' error while trying to do a revert. - The Bushranger One ping only 14:22, 1 October 2013 (UTC)

Text colour coding breaking down after line breaks in infoboxes

I have noticed this problem before and I wonder if here is something I can put in the wikicode that will fix it. Here's an example of an article where this is happening: Wikipedia talk:Articles for creation/Tony Grey. In the edit window, as soon as the line break code is entered in the infobox, all subsequent text is pink, making it hard to pick out embedded items in the text. —Anne Delong (talk) 15:03, 1 October 2013 (UTC)

By "line break code", do you mean a newline, or the <br> tag? Does the text show pink in the edit window, or on the page when viewed? Is this when using the VisualEditor, WikEd, or the traditional editor? --Redrose64 (talk) 16:51, 1 October 2013 (UTC)
Yes, as you can see in the edit window, after the <br> tag, using "Edit Source". The colours are added for visual context while editing, and don't appear on the saved page. —Anne Delong (talk) 17:44, 1 October 2013 (UTC)
I have been able to replicate this - but only if I go to Preferences → Gadgets, and enable "(S) Syntax highlighter: Alternative to the default coloring of wiki syntax in the edit box (works best in Firefox and works almost all of the time in Chrome and Opera)". If you alter those <br> to <br /> the pink background ends immediately after the > as you would expect. Both <br> and <br /> are valid in HTML5, which is what Wikipedia serves at present. --Redrose64 (talk) 19:04, 1 October 2013 (UTC)
Thank you for taking the time to help me out. I'm sorry that I forgot that long ago I had enabled the colours with a gadget. I regularly see articles with <br> in the infoboxes. If they have been deprecated, is there a better way to force an "/n" in an infobox? —Anne Delong (talk) 20:29, 1 October 2013 (UTC)
The <br> tag isn't deprecated; the problem is that the syntax highlight gadget doesn't handle it correctly, although it copes fine with <br />. Changing <br> to <br /> will not alter either the validity or appearance of the rendered page. However, they are not recommended for use as separators in a list. If the various items that they are being used to separate is semantically a list, it's probably better to use one of the templates that mark up the items as a list, which (I am told) will enable screen-reader software to announce them in a more suitable manner. For example, instead of
| associated_acts     = [[Hiromi]] <br> [[John McLaughlin]] <br>
you could use the {{plainlist}} template, like this:
| associated_acts     = {{plainlist|
*[[Hiromi]]
*[[John McLaughlin]]
}}
BTW: that six-string bass that he's playing in the photo is an unusual instrument (even Dave Pegg doesn't go above five), and could do with a mention. Do you happen to know if the tuning is B0 E1 A1 D2 G2 C3; B0 E1 A1 D2 G2 B2; or G0 B0 E1 A1 D2 G2. --Redrose64 (talk) 21:13, 1 October 2013 (UTC)
I'm sorry, I don't know; it's not my article. It's in the Afc and I was just trying to straighten up the citations and having trouble spotting them. My bass looks like this, and has only the usual four strings. But back on topic, I can see that the beginning editors I am working with would be flummoxed if I inserted one templated item inside another in their articles, so I'll try out your backslash suggestion instead, and save the plainlist information for the future when I may need it in one of my own articles. And I'm sorry that I didn't read your first answer carefully enough, mistakenly thinking you said that the tags were no longer valid. Thanks again. —Anne Delong (talk) 21:45, 1 October 2013 (UTC)

Anyone else seeing this

SO, I went to login to Wikipedia and I saw this after I entered my username (but not my password )

File:Wikierror10012013.jpg

I realize anyone can read any messasge on my talkpage, but it's acting like I already logged in. Anyone else seeing that, if so, that looks to me like it would be a security issue  KoshVorlon. We are all Kosh   16:58, 1 October 2013 (UTC)

You see this if you go to Special:UserLogin if you already are logged in. Are you sure that you hadn't already logged in? I seem to have different expiry dates for different cookies, which might cause something like this if forceHTTPS expires without some other cookies expiring. If you don't have any forceHTTPS cookie (either because it has expired or because you have lost it for some other reason), then you should be logged in on HTTPS pages but logged out if you go to an HTTP page. The login page is an HTTPS page, but you might have been on an HTTP page before that. --Stefan2 (talk) 17:22, 1 October 2013 (UTC)
Please note that File:Wikierror10012013.jpg does not have a valid license. This is primarily because it includes copyrighted logos, such as the Wikipedia puzzle ball, inclusion of which should be licensed {{Wikipedia-screenshot|en|logo=yes}}. The image should also be cropped to omit the irrelevant content, such as that "Wolverine" stuff at the top. More at Wikipedia:Screenshots of Wikipedia. --Redrose64 (talk) 18:39, 1 October 2013 (UTC)

Java script attack?

I dont know for java, but it looks like there are at least a couple of IPs 187.4.152.90 (talk · contribs · WHOIS) and 189.125.47.91 (talk · contribs · WHOIS) attempting to insert java code into the sandbox over the past couple of days.

Is there anything malicious they could be doing or is the site secure from such attacks? -- TRPoD aka The Red Pen of Doom 19:35, 1 October 2013 (UTC)

They're copying and pasting text, so it won't do anything. If they had added javascript to a .js page, that would do something, but this is no different than any litany of code examples we have in articles. And anyway, these are just includes, so there is no actual code. PS: Java does not equal Javascript. Chris857 (talk) 19:44, 1 October 2013 (UTC)

Special pages

Does anyone know why "special pages" are not updated from the 10th of September? david1955 (talk) 03:48, 2 October 2013 (UTC)

Which ones? They are generated in different ways. --Redrose64 (talk) 09:21, 2 October 2013 (UTC)
for example "Uncategorized pages" and many others which were previously updated every day david1955 (talk) 13:41, 2 October 2013 (UTC)
Link: Special:UncategorizedPages -- ToE 14:11, 2 October 2013 (UTC)
ok, but it is not updated from the 10th of September david1955 (talk) 14:19, 2 October 2013 (UTC)
This is a repeat of #Cached special pages not being updated, above, which mentions bugzilla:53227. But there's nothing in the thread or at Bugzilla about when it might be fixed. -- John of Reading (talk) 14:33, 2 October 2013 (UTC)
ok. Now it is clear david1955 (talk) 14:52, 2 October 2013 (UTC)

Automated script installer

I wrote an automated script installer (which is itself a script, of course) that I'd like to eventually include in the documentation at WP:US. Go to User:Equazcion/ScriptInstaller if you want to test it out. Let me know if you run into any issues. equazcion | 05:05, 2 Oct 2013 (UTC)

To whoever may have installed this, I was fixing things until a few moments ago, so behavior might have been unexpected. I believe I got it all ironed out now. Again let me know if you notice any issues. equazcion | 12:13, 2 Oct 2013 (UTC)
I like the concept. Feature improvements:
  • It doesn't detect which scripts I already have installed (User:Cacycle/wikEd.js does know, so I'm sure that logic can be adapted)
  • It isn't aware of the gadgets (which I'm not sure why are on the user script page) I'm using. (User:Cacycle/wikEd.js again)
  • It could be improved to be able to switch gadgets on or off using API:Options.
  • It would be nice if there was a way for it to not offer me to install scripts that won't run on my skin. (User:Cacycle/wikEd.js has skin detection)
Just my first thoughts. I'm sure I can come up with more though with a little thought. :) Technical 13 (talk) 13:42, 2 October 2013 (UTC)
Thanks -- although I'm actually not looking to expand the features. I'm going for simplicity and quickness in the install process -- as well as, perhaps selfishly, simplicity of maintenance, as these things tend to get big and abandoned. I feel user scripts aren't utilized enough, and if more non-techie people had access they'd find them incredibly useful. So my goal was to make the script list a simple point-and-click endeavor, and hopefully I got that down. :) equazcion | 14:06, 2 Oct 2013 (UTC)
Ahh. So, the script installer doesn't allow un-installs. That just seems like it will cause more annoyance on the THQ/HD/VPT asking "how do I remove this script?" No? Technical 13 (talk) 14:14, 2 October 2013 (UTC)
It allows uninstalls of anything it installed. I don't want to have the script attempt uninstalls of scripts that were coded in manually, and don't want to have it list anything that it can't uninstall. If that makes sense. equazcion | 14:16, 2 Oct 2013 (UTC)
It kind of does from a techie perspective, but if this script was written with non-techies in mind, then I think it will be confusing to its target audience. However, I'm perfectly happy to let it sit and see what kind of use it gets and see what happens. :) Technical 13 (talk) 14:56, 2 October 2013 (UTC)
In other words, it's aimed primarily at easing the lives of people who likely wouldn't have installed things manually already -- it's actually just people like you and I, who already have stuff in their common.js, who could possibly get confused, as they don't see the stuff they already put in there. In any event, it's all spelled out pretty clearly on the documentation page, should anyone become confused. equazcion | 15:06, 2 Oct 2013 (UTC)

universal account

I created a universal account "Keysanger". Can I delete this Universal account only in some projects and continue to use my old accounts there?. --Best regards, KS (wat?) 09:11, 2 October 2013 (UTC)

Since WP:SUL was brought in (May or June 2008), newly-created accounts have had the same login ID across all wikis (although occasional problems do occur). There is currently a plan to bring older accounts into the SUL system, which looks like taking longer than anticipated. If you wish to rename an existing account, see WP:CHU, but it is unlikely that you will be permitted to use different account names on different projects on a long term basis. --Redrose64 (talk) 09:31, 2 October 2013 (UTC)
I disagree. Unless you bring attention to yourself, no-one is going to stop you being called JohnSmith on one wiki and BobJones on another, assuming you don't use both on the same wiki (this can get quite difficult given that you login centrally). Just opt not to use those accounts you don't want to use. - Jarry1250 [Vacation needed] 18:50, 2 October 2013 (UTC)
Central login can partially be switched off. Block all third-party cookies and block login.wikimedia.org from using cookies at all. This allows you to log in using one username per domain. However, you still can't use different user names for different subdomains of the same domain. Convenient for me who needs to be logged in under one username on Wikipedia and under another username on Commons whilst waiting for WP:SUL/F. --Stefan2 (talk) 22:06, 2 October 2013 (UTC)

Glitch

Theres a glitch where most pages are not showing the last few edits for me. its showing me an old version. Why is that? How to fix it? Pass a Method talk 09:48, 25 September 2013 (UTC)

Exactly the same for me above. And it's not clearing over time. I'm seeing pages days old now. Deleting all local cached internet files does not clear it. Purging Wikipedia cache does not clear it. Sometimes it randomly clears itself, and then a little while later goes back to showing the old pages. Something is wrong. 86.160.220.63 (talk) 11:27, 25 September 2013 (UTC)
If this is still a problem, do you have a link where I could see it? --AKlapper (WMF) (talk) 12:08, 26 September 2013 (UTC)
Well, you may not see it (depending, I suppose, on which server you connect to??). Also, the suggestion is that you won't see it anyway if you are logged on. Two example pages where I am repeatedly seeing stale content:
http://en.wikipedia.org/wiki/Talk:USS_Skate_(SSN-578) (do not see my edit of 03:37, 24 September 2013)
http://en.wikipedia.org/wiki/Wikipedia:Miscellany_for_deletion/Wikipedia:WikiProject_Containers (do not see JohnCD's edit of 17:36, 25 September 2013‎)
Both these were up to date earlier today when I checked; now they are both back to being stale. This page (VP/T) appears to be up-to-date as I write, but has been very variable over recent days. From time to time I see an up-to-date page; then it goes back to being a random old version. 86.160.222.175 (talk) 17:40, 27 September 2013 (UTC)
  • For the record, for me this problem has now finally cleared on all pages that exhibited the problem that I made a note of. I guess something finally worked its way through the system. 86.160.84.127 (talk) 22:53, 3 October 2013 (UTC)

Show Preview and Show Changes?

I've hesitated to post this until now -- it seems such an obvious idea that it seems like it must have come up before, but there's nothing I can find in the archives.

Why do I have to choose between Show Preview and Show Changes? Why can't I push one button and get both at once? EEng (talk) 03:12, 26 September 2013 (UTC)

Hmmm... those are reasonable questions. I'm not sure. I guess as the individual actions were implemented, developers thought one action per button would be clearest/cleanest.
Special:Preferences#mw-prefsection-editing has some preview-related options, but none that probably do what you want. I searched around Bugzilla for a relevant bug, but didn't see anything. You should consider filing a bug there. I'm not sure a single button is the right answer, but re-thinking the overall workflow might be nice. (Arguably this is what VisualEditor is doing, but we can continue to improve the source/wikitext editor, of course.) --MZMcBride (talk) 06:59, 26 September 2013 (UTC)
At least for me when I do show changes, I get the diff at the top and the rendered page below it. Werieth (talk) 13:10, 26 September 2013 (UTC)
Are you sure you're not looking at a diff (off your watchlist etc.)? Those do show diff + rendered page (though of course no edit box). Otherwise, I sure would like to know how you get that to happen! EEng (talk) 13:59, 26 September 2013 (UTC)
Werieth, are you sure you're not using a gadget like wikiEd or something else? πr2 (tc) 15:29, 26 September 2013 (UTC)
So is there, or is there not, some whatchamajigger thing I can install to get such functionality? Or should I make a request somewhere? I'm not foolish enough to predict no one will find fault with such an idea, but I venture to say it can't be too controversial. EEng (talk) 16:08, 28 September 2013 (UTC)
You can file a bug in Bugzilla, if there isn't one already. It's possible that a JavaScript gadget or MediaWiki extension can already do this. This could also possibly go into MediaWiki core. A Bugzilla bug will properly track the idea, regardless of resolution. --MZMcBride (talk) 03:24, 30 September 2013 (UTC)
Thanks. But do I really have to create an account there? If I have to remember one more password my brain will explode. EEng (talk) 14:41, 3 October 2013 (UTC)

An image deleted as unused when it was used

Yes, my understanding is that files merely linked (rather than embedded) are not counted under "file usage".[25] So, in particular, sound files are not included. This leads to incorrect tagging and deletion. To add insult to injury, once such a file has been deleted a bot comes round and removes the link from the article on grounds that the file does not exist.[26] Thincat (talk) 09:29, 28 September 2013 (UTC)
PS "What links here" does show the usage.[27] I see the WP:CSD#F5 submission was made using Twinkle.[28] Does Twinkle detect orphaned files itself and could its methodology be improved? Do deleting admins take proper account of the matter? Thincat (talk) 09:40, 28 September 2013 (UTC)
The file is in fact orphaned, and its usage on that article fails WP:NFC. Ill be nominating it for deletion shortly. Werieth (talk) 14:56, 30 September 2013 (UTC)
Well, we shall just have to let other people investigate who is right and who is wrong. Thincat (talk) 14:45, 4 October 2013 (UTC)
Colon-linking is not considered a "use" of the file by NFC policies - it's either displayed in context, or not used. --MASEM (t) 14:49, 4 October 2013 (UTC)
Oh, that surprises me (but I know you are much better informed on these things than I am). It that documented somewhere? It seems strange that not showing an image is more likely to breach our fair use policies than actually displaying one. What about fair use audio files? You need to a click from the article to hear those. Thincat (talk) 15:09, 4 October 2013 (UTC)
When using audio it displays the media player. Sites that auto play video's and sound are evil and should be shot on sight. Because the file is rendered in the player it is considered used. Linking to and never actually including the picture is a violation of WP:NFCC#7. If all you are doing is referring to a picture why not use an outside source for the image? Werieth (talk) 15:33, 4 October 2013 (UTC)
That seems a very strained reading of WP:NFCC#7 to me. You ask why not use an outside source. In this case the source is a DVD cover so it could be linked to here. Does this approach have the support of WMF, policy or consensus? Thincat (talk) 15:47, 4 October 2013 (UTC)
It has always been consensus of #7 that a file must be used in at least one article, just linking to an image has never been considered usage. If you are just linking and not displaying it typically means that that usage would also fail other NFCC points (#8 would be the most common.) Werieth (talk) 15:52, 4 October 2013 (UTC)
  • It isn't really used, and the mention it has seems to be a piece of original research. Do you have a source that indicates that that image was mistaken?—Kww(talk) 21:29, 4 October 2013 (UTC)
  • Even if it is not original research, it is not necessary to see a picture of a DVD cover to show that the movie used the wrong type of breathing aparatus - this can be explained in text, if the source to avoid OR is found.--MASEM (t) 21:33, 4 October 2013 (UTC)
  • I thought that the rule against WP:OR stops short of total obviousness. And here it is referenced :: the image is the reference, plus anyone who has seen the film. It is allowed to have a reference that states a fact in words :: here is a reference that shows a fact as an image. Anthony Appleyard (talk) 05:36, 5 October 2013 (UTC)
    • In articles about countries, the infobox names the country's capital, but there is usually no source for the claim that this city is the capital. This would appear to be original research but still not disallowed since it is so obvious that the claim is correct (just check any map of the country). Only in special cases such as the Republic of China do articles list a source for the capital city (some documents say Taipei, other documents say Nanking). --Stefan2 (talk) 09:43, 5 October 2013 (UTC)
    • Total obviousness to everyone, not just those in the field. If its obvious to those that know scuba but not to those that don't, it needs a source. And the current attempt to avoid OR (pointing out what was actually being used at the time the movie was made) is not sufficient. You need an RS (not a blog) that says this was a movie mistake. Even then if you could source it, the reader gains nothing new from seeing the image; if you really need to show the differences you can use free images to show typical equipment that the movie used and what the actual military was using at the time. --MASEM (t) 13:54, 5 October 2013 (UTC)
  • In this edit of page Frogman I changed this link to a displayed image. Anthony Appleyard (talk) 09:11, 5 October 2013 (UTC)
  • At Wikipedia:Files for deletion/2013 October 5#File:Frogmendvd.jpg someone is trying to get this image deleted. Anthony Appleyard (talk) 12:39, 5 October 2013 (UTC)
  • There seem to be two topics here:-
    1. Is this image acceptable under "fair use"?
    2. Before I changed its use in page Frogman from a link-to to a displayed image, it was reported as unused when it was used; does linking to an image with a link starting with a colon, count as a use of that image?
    Anthony Appleyard (talk) 15:03, 5 October 2013 (UTC)
    To the second point, No, unless an image is displayed its not used. Referring to an image using the : prefix is similar to using {{}} vs [[]] for templates. Werieth (talk) 15:06, 5 October 2013 (UTC)

File Format Expert

Related discussion: commons:Commons:Village pump#Compression

I put together the Absurd overhead report at Commons after finding a GIF with PHP exploit code. Many of these files are uncompressible (lacking redundant data), but the optimizers discard 70+% of the size. We deleted the RAR archives and have a crude check for ICC profiles. So what else could the extra data be? — Dispenser 03:01, 1 October 2013 (UTC)

Probably depends on the image. For example, File:M734 Parts.png has a huge private chunk named "cpIp". Extracting the data from that chunk, it's identified as "Composite Document File V2 Document, No summary info". It wouldn't surprise me if that turns out to be some proprietary program's native format, embedded in the PNG so that program can still edit the text and vector bits of the image. Anomie 11:39, 1 October 2013 (UTC)
And File:Bearing Suspense Taboo.JPG has an appended 7z archive, which is password protected. So almost certainly some sort of warez or other crap we don't want. The jpg itself is only 103199 bytes long. Anomie 12:16, 1 October 2013 (UTC)
Adobe Fireworks saves to a proprietary PNG format as its native source format, with all object and layer data etc, plus a flattened raster for general display. Those could be uploads where people neglected to export and just uploaded their Fireworks source files. equazcion | 12:26, 1 Oct 2013 (UTC)
The sample Fireworks files from Adobe's website all match the 7z 6-byte magic number. All the files (including the JPEGs) match 7z magic number too, but fewer contain the string "Fireworks". I'll have to add this to the report. — Dispenser 15:02, 1 October 2013 (UTC) Mistaken, apparently grep ignores binary characters. Using bgrep now. — Dispenser 19:51, 1 October 2013 (UTC)
For those who are interested, embedded password-protected archives were previously discussed at Commons:Commons talk:Criteria for speedy deletion#password protected embedded files. --Stefan2 (talk) 17:31, 1 October 2013 (UTC)
I took a look at a few more of these now. File:Logo MdV 2012web.jpg and File:Revanlogo.jpg have insanely huge embedded ICC profiles, I don't know if it's stupidity or embedded data of some sort. I see a bunch of the PNGs have large "mkTS" and numerous large "mkBT" chunks, which are probably those Fireworks files that were mentioned. Anomie 21:19, 1 October 2013 (UTC)
Those two files have been nominated for speedy deletion as copyright violations (non-free logos). That way, we should also get rid of any embedded data. --Stefan2 (talk) 21:41, 1 October 2013 (UTC)
Fireworks files typically have many non-standard PNG chunks interspersed between smallish IDAT chunks. The PNG I examined with a "cpIp" chunk did not have this structure. The "Pngcheck" command line program can show exactly what chunks are present in a PNG, and whether there's additional bytes after the end of PNG data... AnonMoos (talk) 07:30, 2 October 2013 (UTC)
I've marked the files containing the "Fireworks" string on the list. We really should get someone with access to the latest version of Fireworks to try and open them. Maybe contact the Graphics Lab? — Dispenser 03:00, 3 October 2013 (UTC)
I have the latest Fireworks (CS6). 7 of the first 10 I tried opening contained multiple layer and object data. I'm not sure if that's all you wanted to check for, but let me know. equazcion | 03:11, 3 Oct 2013 (UTC)
If you could tag them with {{Fireworks PNG}} the would be great. — Dispenser 05:13, 5 October 2013 (UTC)
Okay, I think I got em all. I tagged everything you listed as Fireworks that contained multiple layers/objects. equazcion | 07:00, 5 Oct 2013 (UTC)
Great. Would you mind check the original version of File:German part of Silesia.png (Garbage data appended), File:United Development Party PPP 1997.png ("Adobe Fireworks CS4"), File:Maelstrom, Carta Marina.png (IIRC a JPEG inside cpIp chunk). I will add more magic number check to the list later today. — Dispenser 18:24, 5 October 2013 (UTC)
I should spend a few words on color profiles. sRGB is the default based off the typical CRT calibration in the 90s and similar TVs. The original 1953 NTSC color gamut was larger, but this was reduced for brighter phosphors. If you want deeper colors on an DLP/Laser/OLED screens, you need a color profile to mix source mediums correctly.
Now implementation is kinda screwy. First off, Internet Explorer doesn't support color management, so everything looks dull. Second, Firefox and Webkit (Safari/Chrome) only include an sRGB profile so we need to embed the entire profile (often 500 KB) instead of simply referencing it. Third, our thumbnail/scaler always include the profile for proper display so we have 530 KiB profile include with a 2 KiB 48x32 thumbnail. Finally, only Apple really calibrates their screens, Samsung's OLED phones will happily cast a green tint on every pixel. — Dispenser 03:00, 3 October 2013 (UTC)

api.php?action=query&prop=extract returns incomplete extract for articles.

I am trying to developing a webapp for Wikipedia using its API.
To get the content of the title 'Poole', I am using the following API.
Wiki API Call for Poole
But I do not get the section data for References and Notes. It only contains empty h3 tags as follows;
<h2>References and notes</h2> <h3>Notes</h3> <h3>Bibliography</h3>
If I see the same article in the mobile view of Wikipedia then I can see the entire data for the entire section.
URL for the same - https://en.m.wikipedia.org/wiki/Poole
Can you please let me know what I am doing wrong ? or is there any issue with the Wiki API ? — Preceding unsigned comment added by Harin4wiki (talkcontribs) 11:06, 1 October 2013 (UTC)
Pages don't actually contain references in those sections. References and notes sections are mostly generated on-the-fly by templates, usually the {{reflist}} template, using code found throughout the rest of the article text in <ref> tags. That's why the API doesn't deliver references in those sections -- they aren't actually there in the saved page code. equazcion | 11:34, 1 Oct 2013 (UTC)
You should probably disregard what I just said, on second thought. I notice you're getting html coded output from the API, rather than wikicode, which I guess should contain the references (I'm not entirely sure). Perhaps someone else can explain. equazcion | 11:45, 1 Oct 2013 (UTC)
Okay, first, let's offer others responding an easier to read api link: https://en.wikipedia.org/w/api.php?action=query&prop=extracts%7Cpageimages%7Clinks&piprop=thumbnail%7Cname&pithumbsize=240&plnamespace=0&pllimit=500&format=jsonfm&redirects=&titles=Poole
Next, what do you mean by "section data"? Do you mean the content of what is in those sections? If that is the case, then you want the full page content using: https://en.wikipedia.org/w/api.php?action=query&prop=revisions%7Cpageimages%7Clinks&rvprop=content&piprop=thumbnail%7Cname&pithumbsize=240&plnamespace=0&pllimit=500&format=json&redirects=&titles=Poole (human friendly version) replacing "extracts|" with "|revisions&rvprop=content" of which will give you the wikitext of the page that you will have to parse the page data yourself to get the list of references. Or... You could just do an HTML scrape on the page itself if you are doing this from outside Wikipedia instead of a userscript that runs on the page itself. If you are doing on the userpage itself, then just use jQuery to find the information you want.
I'll need more details to help you further. Technical 13 (talk) 12:21, 1 October 2013 (UTC)

Thanks for the help. Getting the extract was much more simpler and easier to parse then getting the revision so I was using that method. Also I am getting the text without HTML and then formatting the same for my application. Still, I will check the modified API you have given to see if that suffices my need. I would not like to HTML scrape through the page itself as that is not too reliable. I want to use only API so that I am also sure the data which I get. comment added by Harin4wiki (talk) —Preceding undated comment added 06:19, 4 October 2013 (UTC)

Yes, by section data I meant the content in those sections. I am interested in limited HTML and thats why I am using the prop=extracts API call. Is there any other way by which I can get the information as I get in action=query&prop=extracts ? - Harin4wiki (talk) —Preceding undated comment added 13:21, 4 October 2013 (UTC)

20:00, 2 October 2013 (UTC)

Note that, as communicated here and at MediaWiki, the above VisualEditor news is incorrect. Rather frustrating that this gets distributed like this anyway... Fram (talk) 06:56, 3 October 2013 (UTC)

Help with Pywikipedia

I downloaded Pywikibot from MediaWiki here, and moved the "core" folder to the C:\ folder on my (Windows) computer. When I ran login.py from the command prompt, I received the following error:

Traceback (most recent call last):
  File "C:\core\pywikibot\login.py", line 15, in <module>
    import pywikibot
ImportError: No module named pywikibot

What am I doing wrong? -- Ypnypn (talk) 21:18, 2 October 2013 (UTC)

I have not modified any of the files (except obviously user-config.py). -- Ypnypn (talk) 00:51, 3 October 2013 (UTC)

@Ypnypn: Run it as 'pwb.py login' (pwb.py is in the main core directory). For all scripts you want to run, just put 'pwb.py' in front. Legoktm (talk) 02:22, 3 October 2013 (UTC)
@Legoktm: That works, but when I tried the same thing with the other scripts (such as 'pwb.py fixes') the computer can't find the file (even though it's in the same folder as login.py). -- Ypnypn (talk) 16:39, 3 October 2013 (UTC)

No POTD output for languages other than English using wiki API

Dear All,

Problem Description:

  	-We have found out that "Picture of the day" and "Today's Article" are working fine for 'English' language. 

-However, for languages other than English using the standard API, we are not able to get the required data. -Searched the forum but was not able to locate a specific article.

Details:

 Operating System	:  Win7
 Browser		:  Google Chrome: Version 26.0.1410.64 m
 Page/File		:  Picture of the day (Italy language) - Using Wiki API.
 POTD Wiki API (Italy) :  https://en.wikipedia.org/wiki/Special:ApiSandbox#action=featuredfeed&format=json&feed=potd&language=it


Here's are the test results:

POTD for ‘Italy’

Issues Observed:

1. The data is not in JSON format. 2. Though the language parameter states ‘Italy’, the output text is still of English-POTD.


Interested Languages : French, Italy, German,Spain,Russia,Portugese,Arabic.

Your help would be appreciated — Preceding unsigned comment added by Jainhemendrah (talkcontribs) 09:42, 3 October 2013 (UTC)

You'll probably want to specify the language code in the URL before Wikipedia: it.wikipedia.org, for example. I don't know offhand what the language token would do in the API, or if it's supported at all -- but making a request from English Wikipedia (en.wikipedia.org) is not likely to produce anything but english-language output. equazcion | 10:22, 3 Oct 2013 (UTC)
As for the formatting thing, you're requesting a feed, so I think you might be limited to XML or whatever the feeds use (I don't know much about them). If you were requesting an article, the format token would be respected. equazcion | 10:37, 3 Oct 2013 (UTC)
  • What you're doing here is requesting the English Wikipedia's Picture of the Day - the API is on en.wikipedia.org - and setting the interface language to Italian. To get the Italian Wikipedia's Picture of the Day, you'd need to use the API on it.wikipedia.org. Andrew Gray (talk) 11:41, 3 October 2013 (UTC)

Https issue

I'm suddenly unable to access Wikipedia via http; it keeps defaulting to https no matter what (I do have https turned off in the Preferences, and everything worked just fine only yesterday). Thoughts?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 3, 2013; 13:32 (UTC)

See This section above though why it takes weeks to undo a bad change, I don't know. Arjayay (talk) 14:20, 3 October 2013 (UTC)
Thanks. I've seen that thread, but it's been posted a week ago, and everything worked fine on my end only yesterday, so I'm not sure if it's the same issue or not...—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 3, 2013; 14:36 (UTC)
I've just checked the bugzilla thread, and one of the solutions suggested there is to manually remove the forceHTTPS cookie. Doing so has helped (for how long, I don't know).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 3, 2013; 14:40 (UTC)
Earlier this morning I noticed the same issue, even though I disabled the "always use a secure connection when logged in" option weeks ago (which, by the way, I never enabled: it randomly auto-enabled itself for no reason at all), now I saw this and I tried to delete the "forceHTTPS" cookie, which fixed it for me, as well. I seriously hope they're not going to enforce https to everyone, though.
Nineko (talk) 17:38, 4 October 2013 (UTC)
It's not really resolved - knowing about the issue is not the same as fixing it. Any update on this? Lugnuts Dick Laurent is dead 17:59, 4 October 2013 (UTC)

Would it be possible to mark edits made using APIs as such

Just like we denote edits by bots and edits marked as minor? Or atleast put an edit filter to monitor them? (Sorry if some mechanism is already there) Thanks···Vanischenu (mc/talk) 14:07, 3 October 2013 (UTC)

I don't think we need more tags on edits. We have too many already and there's little value in doing so. If someone is making a vast amount of edits in a small amount of time it's likely they're using the API. Killiondude (talk) 17:08, 3 October 2013 (UTC)
Why? What's the point? Legoktm (talk) 17:21, 3 October 2013 (UTC)
YI think it might allow you to estimate the proportion of spambots that were using the API. Perhaps API + URL would be what you wanted to tag, if that's goal. WhatamIdoing (talk) 18:43, 3 October 2013 (UTC)
Every tag requires an edit filter, and every edit filter slows down the servers a slight bit, because every single edit by every single registered user and by every single IP address is checked against every single edit filter. Each filter takes an extremely tiny amount of time to check, but when you consider how many filter checks must be made, you'll see how much time each new filter requires. As a result, it's really not a good idea to introduce a new filter, unless (1) it's good for fighting substantial disruption, or (2) we really really need to see who's doing what, e.g. the tag for Visual Editor. This really isn't either of those situations. Nyttend (talk) 03:49, 4 October 2013 (UTC)
For the most part, I think they do. VE edits get marked. I see AWB and Twinkle specific tags. I don't know if these are technically edit filters, or just standard additions on edit summaries, but the API tools I'm aware of get marked. VanIsaacWS Vexcontribs 03:55, 4 October 2013 (UTC)
For the curious, we do have data, such as this dashboard, which shows API edits vs regular edits. It's not hard to get this data. I agree with Killiondude though. What's more interesting is what kind of user or tool made an edit (Was it a bot? Huggle? What?), and that just saying the edit came from the API is not that informative. Steven Walling (WMF) • talk 04:34, 4 October 2013 (UTC)

Thanks for all the replies. I was thinking that it would help in finding out the running of unapproved bots (and since the edits by tools using api will indicate it in edit summaries/tags, the api edits other than them will standout.) But it seems that there is no real advantage in doing so (as running of spambots can be detected by the speed itself. And even if it were of any help, an external tool would have been the better solution than the ones I specified.) Thanks again···Vanischenu (mc/talk) 12:44, 5 October 2013 (UTC)

GeoGroupTemplate issues

What's going on with {{GeoGroupTemplate}} suddenly today? Using two different computers and two different browsers, I've tried to get coordinates mapped onto Google like normal, but all that happens is errors: either HTTP502 Bad Gateway appears and I get nothing, or a blank map appears with a note of "File not found at...". I never do anything with Toolserver except for {{coord}} and related mapping tools, and simply clicking on a single coordinates location is still working (for example, clicking on 38°53′52″N 77°2′11″W / 38.89778°N 77.03639°W / 38.89778; -77.03639 will drop you in Washington, D.C. just like normal), so I expect that it's not something related to yesterday's security breach — especially since the GeoGroupTemplate was still working fine a couple of hours after the breach was announced and I had to reset my password. Nyttend (talk) 17:40, 3 October 2013 (UTC)

Auto-logout

Resolved

Why do I keep getting logged out after a minute or so??? Today, when I first tried to login, I was asked to change my password, which I did willingly. After a minute or so, I clicked on a link and found myself logged out. This has happened three times, now. One time, I edited a page and clicked on Show preview and found myself logged out again. HELP!!! (and Joys! – Paine Ellsworth CLIMAX!) 97.96.192.146 (talk) 22:11, 3 October 2013 (UTC)

Did you click on "keep me logged in"? Are you in private mode? Does your browser accept cookies? VanIsaacWS Vexcontribs 23:56, 3 October 2013 (UTC)
(IE10 in Win8:)
  1. . No, never have,
  2. . No, never,
  3. . Yes, no security nor privacy settings have been changed. Is there a setting I need to alter? 97.96.192.146 (talk) 00:16, 4 October 2013 (UTC)
I do remember years ago when I tried to use the secure login feature. I was told that I would have to reduce the setting that accepts cookies to its lowest possible value. I was and still am unwilling to do that, which is why I've always used the HTTP level. 97.96.192.146 (talk) 00:25, 4 October 2013 (UTC)
Not surprisingly, I don't seem to have this problem in Firefox, with which I am now logged in. – Paine Ellsworth CLIMAX! 00:39, 4 October 2013 (UTC)
I just tried some tests with my IE cookie monster. Even when the lowest privacy settings are set, I still have the same problem. In fact, with the lowest cookie settings it only seems to take about 30 seconds for me to get knocked off. Oy! (That's the center of Joys!) – Paine Ellsworth CLIMAX! 00:56, 4 October 2013 (UTC)

Seems to be okay, now. Joys to all! – Paine Ellsworth CLIMAX! 09:08, 7 October 2013 (UTC)

Wikipedia, an insecute site?

I'm recently getting an alert from FireFox while editing. See: [36]. Kudpung กุดผึ้ง (talk) 07:58, 4 October 2013 (UTC)

Probably down to some of the scripts you use. You could try editing your vector.js and removing the http: from http://ru.wikipedia.org/. -- WOSlinker (talk) 10:31, 4 October 2013 (UTC)
In that particular link, changing http:// to https:// will fix it. I'm not sure if you have any others that cause problems. Jackmcbarn (talk) 14:58, 4 October 2013 (UTC)

User:Aditya Kabir/106 - this page is not showing

I accidentally created it over User:Aditya Kabir/105, then moved it and restored the content of 105. Now 106 isn't showing. Waht to do? Can someone help? Aditya(talkcontribs) 09:00, 4 October 2013 (UTC)

Found the problem. Solved. Aditya(talkcontribs) 09:12, 4 October 2013 (UTC)
What was the solution? It still shows a redlink here. RudolfRed (talk) 01:39, 5 October 2013 (UTC)

Are automatic PDF downloads a bad thing/security threat? Are they prohibited?

The PDF I found for the following source: Wassersug, Richard J. (1 April 2009). "The Social Context for Psychological Distress from Iatrogenic Gynecomastia with Suggestions for Its Management" (PDF). Journal of Sexual Medicine. 6 (4): 989–1000. doi:10.1111/j.1743-6109.2008.01053.x. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help) is to a url that initiates an automatic download. Is this appropriate for inclusion in a citation template? I want people to be able to see the source, but it's odd how you don't get a new browser window. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 10:26, 4 October 2013 (UTC)

I don't immediately see how it is bad. <devil's advocate>What if the source is a Word Document, or something else like that; it will probably download. Also, if you use firefox, and don't have something to display the PDF in-browser, it will download.</devil's advocate> Chris857 (talk) 14:30, 4 October 2013 (UTC)
All that is is a link to a PDF. What your browser does when it follows a link to a PDF is entirely up to it; it's not something Mediawiki tells it to do. There are tons of direct PDF links in article citations. There is a third-party browser extension from Nitro Software for some popular browsers that presents a dialog with options when following PDF links, if you are interested. If you wish to enhance your own system's security, by far the best thing you can do in regards to PDF files is remove Adobe Acrobat from your system and use an alternative PDF reader, as Acrobat has a many-year history of enormous security holes that Adobe takes forever to patch (as does most software from Adobe). Simply downloading a file will rarely if ever present a security risk; most security issues involve you opening a malicious file. This is complicated by the behavior of some software, such as some e-mail clients, to automatically open certain files, but according to your statement that's not an issue here. --108.38.191.162 (talk) 15:40, 4 October 2013 (UTC)
As a general practice I think it is preferable that a convenience link go to an html page that describes the article with optional download, so that the user can see what they are getting (or getting into), rather than automatically downloading. Many sites, esp. journals, have a corresponding html page to accommodate that. At other sites there is no alternative to immediate download, so all the previous comments apply. Which is why I do not set my browser preferences to automatically open anything but html. ~ J. Johnson (JJ) (talk) 20:44, 4 October 2013 (UTC)
There is no html page so I think the PDF is fine then. Thanks all. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 20:52, 4 October 2013 (UTC)

Template documentation header problem

Hi there, I am moving this request from the VisualEditor feedback page. VE is somehow related in that, as the user later found out, the described situation changes when one disables VE from their Preferences, but if the issue is local, maybe some sysop can fix it? Can someone please have a look and tell me if some action is required by the VE developers instead? In this case, I'll file it ASAP. Thanks! --Elitre (WMF) (talk) 11:40, 4 October 2013 (UTC)

Hi.

I am not sure if it is a VisualEditor bug but then, I don't have any other answer for the question "what has caused this issue?" Here we go.

  • First screenshot: Shows Firefox v24.0 loading Template:Documentation/start box, no user has has logged on, the template renders exactly as its code (revision 560807734) logically leads us to believe it would. Now, as you open the next screenshot, pay attention to what you see in front of "Template documentation": You see "[View] [edit] [history] [purge]". It is transcluded in every template that uses {{documentation}} and [view] brings up view mode. So far so good.
  • Second screenshot: Same web browser, I am logged on. The links now read: [Edit source] [edit] [history] [purge]". Problem? Well, this template is transcluded in every template that uses {{documentation}} and clicking [edit source] does not bring up source editing screen; it is still view mode, with the link by mistake saying "edit source".

I tried bypassing my browser cache but that did not do anything good.

Best regards,
Codename Lisa (talk) 10:25, 4 October 2013 (UTC)

Hi. To quickly recap:
  • I tried disabling all my gadgets, commons.js and commons.css but nothing happened. (If there is anything else in Special:PrefixIndex/User:Codename Lisa/ I can disable, please tell me.)
  • Removing the check box from "Preferences → Editing → Usability features → Enable VisualEditor (only in the main and user namespaces)" resolves the issue.
Best regards,
Codename Lisa (talk) 12:30, 4 October 2013 (UTC)
@Elitre (WMF): The problem appears to be in the fact that Template:Documentation/start box uses the mw-editsection class (to get the same styling as section edit links), combined with VE using some JavaScript ("setupSectionLinks") that blindly changes the first link inside an element with class mw-editsection if no such element on the page has a child with the class mw-editsection-visualeditor (on the assumption that the cached HTML was served from before VE was enabled). Chances are the VE JS code could be improved, as duplicating the styling on mw-editsection to avoid VE is probably not something to be desired. Or Template:Documentation/start box could be altered to place "[edit]" first so VE would happen to change the correct link, but I don't know if there are other cases with this same problem. Anomie 14:24, 4 October 2013 (UTC)
@Anomie: I don't think this should be done on VE's side; class=mw-editsection inside a heading is what is used to mark up section edit links, and should not be used for other things. I submitted change https://gerrit.wikimedia.org/r/87627 in MediaWiki core for review; if it's merged and deployed, we could just swap all uses of mw-editsection to mw-editsection-like on-wiki to fix issues like this without losing the styling. Matma Rex talk 21:11, 4 October 2013 (UTC)
Thanks Matma Rex! Keep us posted? :) Below, Salix alba views on the matter. --Elitre (WMF) (talk) 10:58, 7 October 2013 (UTC)

This does sound like a carry over from how the section edit tabs are renamed for VE. Some javascript somewhere is modifying the display of various classes. Looking at the html

<span class="mw-editsection plainlinks mw-editsection-expanded" id="doc_editlinks" style="direction: ltr;">
 [<a href="/wiki/Template:Infobox_book/doc" title="">view</a>] 
 [<a class="external text" href="//en.wikipedia.org/w/index.php?title=Template:Infobox_book/doc&amp;action=edit" title="">Edit</a>] 
 [<a class="external text" href="//en.wikipedia.org/w/index.php?title=Template:Infobox_book/doc&amp;action=history" title="">history</a>]
 [<span class="noprint plainlinks purgelink"><a class="external text" href="//en.wikipedia.org/w/index.php?title=Template:Infobox_book&amp;action=purge#" title=""><span title="Purge this page">purge</span></a></span>]
</span>

This is the same as in the section edit links which also use <span class="mw-editsection mw-editsection-expanded" style="direction: ltr;">. The upshot of this is that the css/js which changes the labels also affects the links in the documentation page. It could be fixed by adding a not(.plainlinks) to the appropriate code, if I could find it.

I would say more could be done to have a simple class for VE edit links, the css you need to find just these is much harder than it needs to be.--User:Salix alba (talk): 12:35, 4 October 2013 (UTC)

How can I get the todays featured article and picture of the day through exapndtemplates API in various languages ?

I require the todays featured article and picture of the day in the following languages; - English - French - Italian - German - Spanish - Russian - Portuguese - Arabic

I have the english API through which I can expand the template and get the featured article but am unable to use that same API call for other languages. The API call in English is as follows; http://en.wikipedia.org/w/api.php?action=expandtemplates&format=json&text=Myalgic encephalomyelitis/chronic fatigue syndrome

The above API returns me the featured article title as below; {

 expandtemplates: {
   *: "Terry-Thomas"
 }

}

I am not sure how to get this same information for other languages. Can anyone give me the magic keywords which I can use in the expandtemplates ? Is there any place where I can see the complete list of magic words that I can use with expandtemplates.

- Harin Sutaria - added by Harin4wiki (talk) 13:06, 4 October 2013 (UTC)

{{TFA title}} is a template, which appears somewhere on the main page. The implementation of the main page is project specific, so no. [37] is probably the closest to what you want, but not all languages are supported. MER-C 13:44, 4 October 2013 (UTC)
This is the same problem as with POTD a few sections above (are you working on the same project?). The API on the English Wikipedia site can only return data from the English Wikipedia; you will need to use the APIs for the French, Italian, etc., Wikipedia sites to get content in those languages. There is no single API for all languages. Andrew Gray (talk) 19:09, 5 October 2013 (UTC)

Yes, Andrew. You picked up that correctly. We are working on the same project. expandtemplates is not working for other languages for TFA and POTD. Scraping of HTML is not a good idea. I want the entire data through the API. So I have a problem in hand. - added by Harin4wiki (talk) 13:54, 7 October 2013 (IST)

The thing to remember is that while the underlying software (the API) is the same for each site, the way the "website" is built on top of it can be very different, and different projects have developed different tools. For example, bthere simply isn't an equivalent to {{TFA title}} in French - it has a template for the daily FA, {{Lumière%20sur/Aujourd'hui}}, but not one for just the title.
So relying on things like the local templates won't work. You'll have to either do a bit of HTML scraping, or rely on the local version of the "featured" feed and see if you can build something on that. Andrew Gray (talk) 22:41, 7 October 2013 (UTC)

I thought it'd be a good idea re-running the script on this page...or even diversifying so we could have one category for most-linked stubs and one for most-viewed stubs. Beland (talk · contribs) I've asked but then I suppose anyone who is good at technical stuff (which I am not) could rejig this/these and see what comes out?

I did have a vague idea of running a de-stubbing contest (much like the Core Contest later in the year to see what we could achieve by hoeing into our vast number of stubs. Cheers all, Cas Liber (talk · contribs) 14:06, 4 October 2013 (UTC)

As a minor musing I have wondered how many stubs have been created by editors trying to boost their "articles created" score. Perhaps there would be less incentive to slap-in stubs if they were counted separately. Even better: let's create a box that automatically appears on one's user page, along with a polite request to finish the jobs. ~ J. Johnson (JJ) (talk) 20:59, 4 October 2013 (UTC)

How to put spaces in a URL anchor

Is it possible to encode a reference to a URL with anchor where the anchor contains spaces?
E.g. http://www.simplifydiy.com/bathroom/bathroom-fixtures/wc-suite/wc-pan-types#Double trap siphonic pan

Leaving the spaces in doesn't work - the first space is taken as the end of the url:
http://www.simplifydiy.com/bathroom/bathroom-fixtures/wc-suite/wc-pan-types#Double trap siphonic pan

Substituting %20 or underscore doesn't work either - neither is substituted back to space when the URL is clicked. http://www.simplifydiy.com/bathroom/bathroom-fixtures/wc-suite/wc-pan-types#Double%20trap%20siphonic%20pan
http://www.simplifydiy.com/bathroom/bathroom-fixtures/wc-suite/wc-pan-types#Double_trap_siphonic_pan

Jim Craigie (talk) 00:03, 5 October 2013 (UTC)

URL anchors refer to the ids of the page elements in the source. You can't have spaces in ids, so trying to link to an anchor with spaces would never work, but from the source of that page, it looks like those sections you're trying to link to don't have ids at all, so there's basically nothing you can do there. (It's good practice to give content sections ids based on their names, which is what mediawiki automatically does when you create a section heading here, but not all sites have that.) -— Isarra 05:28, 5 October 2013 (UTC)
Oh blimey, I just saw the TOC... I see what you mean. That site is using names instead of ids, which is no longer valid usage; browsers just still support it for backward compatibility. Looks like mediawiki assumes things are using a more current spec? There might be a way to force the url, but I dunno what it'd be. -— Isarra 05:41, 5 October 2013 (UTC)
When I click the URL with the %20s, the anchor link works for me (Firefox 24). equazcion | 05:51, 5 Oct 2013 (UTC)
Yes, the version with %20 works for me as well, as I expected it would. I think you expected the %20 to change to space in the url you see on your end in the new window opened for the linked-to content. But that's not the way it works. The %20 is transported to the other end -- see Percent-encoding -- is turned into space at some exquisitely-chosen just-right moment at the other end. EEng (talk) 02:48, 6 October 2013 (UTC)
Thanks for the responses. This may be entirely a problem with the ancient IE8 I'm currently using on a borrowed laptop, but when I click the link with %20s it takes me to the page but does not take me to the specified section of the page, but when I click that section's entry in the page's TOC it does go to that section. Jim Craigie (talk) 11:00, 7 October 2013 (UTC)